Redesigning postmaster death handling - Mailing list pgsql-hackers

From Thomas Munro
Subject Redesigning postmaster death handling
Date
Msg-id CA+hUKGKp0kTpummCPa97+WFJTm+uYzQ9Ex8UMdH8ZXkLwO0QgA@mail.gmail.com
Whole thread Raw
Responses Re: Redesigning postmaster death handling
Re: Redesigning postmaster death handling
List pgsql-hackers
Hi,

Here's an experimental patch to fix our shutdown strategy on
postmaster death, as discussed in a nearby report[1].

Maybe it's possible to switch to _exit() without also switching to
preemptive handling, but it seems fragile and painful for no gain.

Following that line of thinking, we might as well just ask the kernel
to hit our existing SIGQUIT handler at parent exit, on Linux/FreeBSD.
Job done.

For systems lacking that facility, the idea I'm trying out here is
that backends that detect the condition in WaitEventSetWait() should
themselves blast all backends with SIGQUIT, in a sense taking over the
role of the departed postmaster.  I didn't really want any
consensus/negotiation over who's going to do that, so... they all do.

Most of the patch is just removing hundreds of lines of errors and
conditions and comments that were now unreachable.

Better ideas, glaring holes in the plan, etc, welcome.

[1] https://www.postgresql.org/message-id/flat/B3C69B86-7F82-4111-B97F-0005497BB745%40yandex-team.ru

Attachment

pgsql-hackers by date:

Previous
From: Alexandra Wang
Date:
Subject: Re: SQL:2023 JSON simplified accessor support
Next
From: Thomas Munro
Date:
Subject: Re: VM corruption on standby