Re: VM corruption on standby

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, 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-09-10 22:59:19
Message-ID: CA+hUKGLZNMYWj0r5Cda7gBPgJ3wR5wQwvKe9D2DxhVa3thT9zA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 11, 2025 at 12:00 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> > On 10 Sep 2025, at 15:25, Alexander Korotkov <aekorotkov(at)gmail(dot)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...

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-09-10 23:18:13 Re: Incorrect logic in XLogNeedsFlush()
Previous Message Peter Geoghegan 2025-09-10 22:24:16 Re: index prefetching