public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: Matthias van de Meent <[email protected]>
To: Thomas Munro <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Subject: Re: Startup process deadlock: WaitForProcSignalBarriers vs aux process
Date: Wed, 22 Apr 2026 15:05:33 -0400
Message-ID: <ojnnvj553eber32njg5nphybcf6zvb3bzexfkh3obylsll67pc@jk7jmtzeb66k> (raw)
In-Reply-To: <CAEze2WgAJmWReDN7Chtba8Er2YBvKCoa0KVN25-1evnTrHsLyA@mail.gmail.com>
References: <CAEze2WgAJmWReDN7Chtba8Er2YBvKCoa0KVN25-1evnTrHsLyA@mail.gmail.com>

Hi,

On 2026-04-22 13:21:02 +0200, Matthias van de Meent wrote:
> If the PSB is emitted (and signaled to checkpointer) before the
> checkpointer has registered its SIGUSR1 handler, then the checkpointer
> won't receive the notice to check its procsignal slots, it won't
> notice the updated procsignal flags, and it won't process the PSB; not
> until it receives a new SIGUSR1.
> 
> Signals are sent to all processes that have their procsignal pss_pid
> set, which is true for every process which has called ProcSignalInit,
> which for the checkpointer (like other aux processes) happens in
> AuxiliaryProcessMainCommon. However, checkpointer (also like other aux
> processes) calls AuxiliaryProcessMainCommon before registering its
> signal handlers, creating a small window in time where signals are
> sent, but not handled.

Hm. Have we confirmed this happens?

CheckpointerMain() is called with all signals masked, so it should be ok for
the signal handler to only be set up after AuxiliaryProcessMainCommon(), as
long as it happens before

	/*
	 * Unblock signals (they were blocked when the postmaster forked us)
	 */
	sigprocmask(SIG_SETMASK, &UnBlockSig, NULL);

as the signal delivery should be held until after unblocking signals.


> # A solution?
> 
> I don't have one right now.
> I was thinking in the direction of having a compile-time aux process
> signal handlers array per process type, which is read by
> AuxiliaryProcessMainCommon() to register the signal handlers ahead of
> ProcSignalInit(), but I've not yet looked at the exact implications,
> nor analyzed whether that's actually safe. It would move some
> duplicative code patterns into compile-time structs, but that's not
> necessarily a universal good.

We really should move setup of most signal handlers into
AuxiliaryProcessMainCommon(). While there are some special cases (like
checkpointer not wanting to handle SIGTERM), that can be configured after
AuxiliaryProcessMainCommon(), as signals will still be blocked.

Greetings,

Andres Freund

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Startup process deadlock: WaitForProcSignalBarriers vs aux process
  In-Reply-To: <ojnnvj553eber32njg5nphybcf6zvb3bzexfkh3obylsll67pc@jk7jmtzeb66k>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox