Re: VM corruption on standby - Mailing list pgsql-hackers

From Kirill Reshke
Subject Re: VM corruption on standby
Date
Msg-id CALdSSPjTH7f48h6ZGPbi6zuVoByEkM9M-M-94s5nPjiofDA03A@mail.gmail.com
Whole thread Raw
In response to Re: VM corruption on standby  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: VM corruption on standby
Re: VM corruption on standby
List pgsql-hackers
On Tue, 19 Aug 2025 at 10:32, Thomas Munro <thomas.munro@gmail.com> wrote:
>

> I don't know if there are other ways that LWLockReleaseAll() can lead
> to persistent corruption that won't be corrected by crash recovery,
> but this one is probably new since the following commit, explaining
> the failure to reproduce on v17:
>
> commit bc22dc0e0ddc2dcb6043a732415019cc6b6bf683
> Author: Alexander Korotkov <akorotkov@postgresql.org>
> Date:   Wed Apr 2 12:44:24 2025 +0300
>
>     Get rid of WALBufMappingLock
>
> Any idea involving deferring the handling of PM death from here
> doesn't seem right: you'd keep waiting for the CV, but the backend
> that would wake you might have exited.


I revert this commit (these were conflicts but i resolved them) and
added assert for crit sections in WaitEventSetWait.

make check passes (without v2-0001 it fails)


-- 
Best regards,
Kirill Reshke

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Remove traces of long in dynahash.c
Next
From: Andrei Lepikhov
Date:
Subject: Re: Plan caching and serialization for reuse across executions