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 →
  1. Revert "Get rid of WALBufMappingLock"

  2. Get rid of WALBufMappingLock

  3. Split WaitEventSet functions to separate source file

  4. Add WL_EXIT_ON_PM_DEATH pseudo-event.