> The database relies on the data being consistent when it performs crash recovery.
> Imagine that a checkpoint is running while you take your snapshot. The checkpoint
> syncs a data file with a new row to disk. Then it writes a WAL record and updates
> the control file. Now imagine that the table with the new row is on a different
> file system, and your snapshot captures the WAL and the control file, but not
> the new row (it was still sitting in the kernel page cache when the snapshot was taken).
> You end up with a lost row.
>
> That is only one scenario. Many other ways of corruption can happen.
Can we say then that the risk comes only from the possibility of a checkpoint running inside the time gap between the non-simultaneous snapshots?
On Mon, Jan 16, 2023 at 3:37 PM HECTOR INGERTO <hector_25e@xxxxxxxxxxx> wrote:
The data integrity is dependent on writes happening in the order they are issued/confirmed when they are synchronous. Thus terms like WAL = Write *Ahead* Log.
--
