On Mon, 2023-01-16 at 14:37 +0000, HECTOR INGERTO wrote: > > 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?
Another case: a transaction COMMITs, and a slightly later transaction reads the data and sets a hint bit. If the snapshot of the file system with the data directory in it is slightly later than the snapshot of the file system with "pg_wal", the COMMIT might not be part of the snapshot, but the hint bit could be. Then these uncommitted data could be visible if you recover from the snapshot. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
