Re: VM corruption on standby

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Kirill Reshke <reshkekirill(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: VM corruption on standby
Date: 2025-08-20 03:47:21
Message-ID: 933566.1755661641@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Wed, Aug 20, 2025 at 7:50 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2025-08-20 03:49:14 Re: Don't treat virtual generated columns as missing statistics in vacuumdb --missing-stats-only
Previous Message John Naylor 2025-08-20 03:44:02 Re: Enhance Makefiles to rebuild objects on map file changes