Redesigning postmaster death handling

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Redesigning postmaster death handling
Date: 2025-08-21 05:07:06
Message-ID: CA+hUKGKp0kTpummCPa97+WFJTm+uYzQ9Ex8UMdH8ZXkLwO0QgA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
v1-0001-SIGQUIT-on-postmaster-death.patch application/octet-stream 45.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2025-08-21 05:15:25 Re: VM corruption on standby
Previous Message Alexandra Wang 2025-08-21 04:53:53 Re: SQL:2023 JSON simplified accessor support