Re: Startup process deadlock: WaitForProcSignalBarriers vs aux process

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