Horton
Menu

Re: VM corruption on standby

Andrey Borodin <x4mmm@yandex-team.ru>

View thread
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kirill Reshke <reshkekirill@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Melanie Plageman <melanieplageman@gmail.com>, Thomas Munro <thomas.munro@gmail.com>
Date: 2025-08-18T06:43:05Z
Lists: pgsql-hackers 

> On 17 Aug 2025, at 17:33, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> So I think the correct fix here is s/proc_exit(1)/_exit(2)/ in the
> places that are responding to postmaster death. 

+1. But should we _exit(2) only in critical section or always in case of postmaster death?

Another question that was bothering Kirill is do we want a test that naturally reproduces WaitEventSetWaitBlock() under critical section so that we can observe a corruption? Or is it kind of obvious from code that such things might happen?
Existing test is adding WaitEventSetWaitBlock() via injection point to a place where it was not present before. Though with existing test at hand we can check that fix is curing WaitEventSetWaitBlock() against critical section.


Best regards, Andrey Borodin.

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.