Re: VM corruption on standby
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>,
Andrey Borodin <x4mmm@yandex-team.ru>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Melanie Plageman <melanieplageman@gmail.com>,
Michael Paquier <michael@paquier.xyz>
Date: 2025-08-20T03:47:21Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > On Wed, Aug 20, 2025 at 7:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I'm inclined to think that we do want to prohibit WaitEventSetWait >> inside a critical section --- it just seems like a bad idea all >> around, even without considering this specific failure mode. > FWIW aio/README.md describes a case where we'd need to wait for an IO, > which might involve a CV to wait for an IO worker to do something, in > order to start writing WAL, which is in a CS. Hm. It still makes me mighty uncomfortable, because the point of a critical section is "crash the database if anything goes wrong during this bit". Waiting for another process --- or thread --- greatly increases the scope of ways for things to go wrong. So I'm not exactly convinced that this aspect of the AIO architecture is well-thought-out. Having said that, we should in any case have a better story on what WaitEventSetWait should do after detecting postmaster death. So I'm all for trying to avoid the proc_exit path if we can design a better answer. regards, tom lane
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