Re: VM corruption on standby

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, 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>
Subject: Re: VM corruption on standby
Date: 2025-08-20 23:12:36
Message-ID: aKZWZHjSMOhmqfn5@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 20, 2025 at 09:14:04AM -0400, Andres Freund wrote:
> On 2025-08-19 23:47:21 -0400, Tom Lane wrote:
>> 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.
>
> I don't see the alternative:
>
> 1) Some IO is done in critical sections (e.g. WAL writes / flushes)
>
> 2) Sometimes we need to wait for already started IO in critical sections
> (also WAL)
>
> 3) With some ways of doing AIO the IO is offloaded to other processes, and
> thus waiting for the IO to complete always requires waiting for another
> process
>
> How could we avoid the need to wait for another process in criticial sections
> given these points?

Yes, it comes down to the point that for some code path we just cannot
accept a soft failure: some IOs are critical enough that if they fail
the only thing we can should and can do is to recover and replay based
on the past IOs that we know did succeed and made it durably to disk.

Having what can be qualified as safe and efficient to use in a
critical section for event broadcasting and waits would be really,
really nice.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2025-08-20 23:43:49 Re: Remove traces of long in dynahash.c
Previous Message Michael Paquier 2025-08-20 23:07:17 Re: Remove traces of long in dynahash.c