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

From Kirill Reshke
Subject Re: VM corruption on standby
Date
Msg-id CALdSSPgf8N4_eF3U6ReRUGeUPMaGTaNK1fWAbzZ3nnM7ChbsiQ@mail.gmail.com
Whole thread Raw
In response to Re: VM corruption on standby  (Yura Sokolov <y.sokolov@postgrespro.ru>)
Responses Re: VM corruption on standby
List pgsql-hackers
On Tue, 19 Aug 2025 at 18:29, Yura Sokolov <y.sokolov@postgrespro.ru> wrote:


> Latch and ConditionVariable (that uses Latch) are among basic
> synchronization primitives in PostgreSQL.

Sure

> Therefore they have to work correctly in any place: in critical section, in
> wal logging, etc.

No. Before bc22dc0e0ddc2dcb6043a732415019cc6b6bf683 ConditionVariable
code path was never exercised in critical sections. After
bc22dc0e0ddc2dcb6043a732415019cc6b6bf683 it is exercised in almost
every one (if the system is highly loaded). This is a crucial change
with corruption as a drawback (until we fix this).

To replace proc_exit(1) with _exit(2) is not a cure too: if we exit
inside CRIT section without any message to LWLock contenders, they
will never do the same (never exit), because they are wait the
semaphore and do not respond to signals (so, only way to stop them in
to kill-9). Before bc22dc0e0ddc2dcb6043a732415019cc6b6bf683 lwlock
holders did not exit inside crit sections (unless kill9)

I had one suggestion about what can be done [0]. However there is
little no time until the pg18 release for a change that scary and big
(my own understanding), so the safest option is to revert.

[0] https://www.postgresql.org/message-id/CALdSSPgDAyqt%3DORyLMWMpotb9V4Jk1Am%2Bhe39mNtBA8%2Ba8TQDw%40mail.gmail.com
-- 
Best regards,
Kirill Reshke



pgsql-hackers by date:

Previous
From: Yura Sokolov
Date:
Subject: Re: VM corruption on standby
Next
From: Fujii Masao
Date:
Subject: Re: New commitfest app release on August 19th