Re: VM corruption on standby

Alexander Korotkov <aekorotkov@gmail.com>

From: Alexander Korotkov <aekorotkov@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, Kirill Reshke <reshkekirill@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Melanie Plageman <melanieplageman@gmail.com>
Date: 2025-10-03T06:31:33Z
Lists: pgsql-hackers
Hi, Thomas!

On Thu, Sep 11, 2025 at 1:59 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Thu, Sep 11, 2025 at 12:00 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> > > On 10 Sep 2025, at 15:25, Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > >  I believe we need some
> > > general solution.  We might have a special kind of condition variable,
> > > a critical section condition variable, where both waiting and
> > > signaling must be invoked only in a critical section.  However, I dig
> > > into our Latch and WaitEventSet, it seems there are too many
> > > assumptions about postmaster death.  So, a critical section condition
> > > variable probably should be implemented on top of semaphore.  Any
> > > thoughts?
> >
> > We want Latch\WaitEventSet, but for critical section. Is it easier to implement from scratch (from semaphores), or is it easier to fix and maintain existing Latch\WaitEventSet?
>
> FWIW I'm working on a patch set that kills all backends without
> releasing any locks when the postmaster exists.  Then CVs and other
> latch-based stuff should be safe in this context.  Work was
> interrupted by a vacation but I hope to post something in the nexts
> couple of days, over on that other thread I started...

How is it going?

------
Regards,
Alexander Korotkov
Supabase



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.