Re: VM corruption on standby
Aleksander Alekseev <aleksander@tigerdata.com>
From: Aleksander Alekseev <aleksander@tigerdata.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>,
Melanie Plageman <melanieplageman@gmail.com>
Date: 2025-08-09T20:54:42Z
Lists: pgsql-hackers
Hi Andrey, > 0. checkpointer is going to flush a heap buffer but waits on content lock > 1. client is resetting PD_ALL_VISIBLE from page > 2. postmaster is killed and command client to go down > 3. client calls LWLockReleaseAll() at ProcKill() (?) > 4. checkpointer flushes buffer with reset PG_ALL_VISIBLE that is not WAL-logged to standby > 5. subsequent deletes do not log resetting this bit > 6. deleted data is observable on standby with IndexOnlyScan Thanks for investigating this in more detail. If this is indeed what happens it is a violation of the "log before changing" approach. For this reason we have PageHeaderData.pd_lsn for instance - to make sure pages are evicted only *after* the record that changed it is written to disk (because WAL records can't be applied to pages from the future). I guess the intent here could be to do an optimization of some sort but the facts that 1. the instance can be killed at any time and 2. there might be replicas - were not considered. > Any idea how to fix this? IMHO: logging the changes first, then allowing to evict the page.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revert "Get rid of WALBufMappingLock"
- 2ce6abdf5085 18.0 landed
- c13070a27b63 19 (unreleased) landed
-
Get rid of WALBufMappingLock
- bc22dc0e0ddc 18.0 cited
-
Split WaitEventSet functions to separate source file
- 393e0d231405 18.0 cited
-
Add WL_EXIT_ON_PM_DEATH pseudo-event.
- cfdf4dc4fc96 12.0 cited