Re: VM corruption on standby

From: Andres Freund <andres(at)anarazel(dot)de>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, 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-08-19 14:57:43
Message-ID: nhzwd7ae2lasqoadikbq5jhnaejzlqxpwmcmq3il4vtdzozv35@xtzxftuovbyo
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2025-08-20 02:54:09 +1200, Thomas Munro wrote:
> > On linux - the primary OS with OOM killer troubles - I'm pretty sure'll lwlock
> > waiters would get killed due to the postmaster death signal we've configured
> > (c.f. PostmasterDeathSignalInit()).
>
> No, that has a handler that just sets a global variable. That was
> done because recovery used to try to read() from the postmaster pipe
> after replaying every record. Also we currently have some places that
> don't want to be summarily killed (off the top of my head, syncrep
> wants to send a special error message, and the logger wants to survive
> longer than everyone else to catch as much output as possible, things
> I've been thinking about in the context of threads).

That makes no sense. We should just _exit(). If postmaster has been killed,
trying to stay up longer just makes everything more fragile. Waiting for the
logger is *exactly* what we should *not* do - what if the logger also crashed?
There's no postmaster around to start it.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2025-08-19 15:16:12 Re: analyze-in-stages post upgrade questions
Previous Message Thomas Munro 2025-08-19 14:54:09 Re: VM corruption on standby