Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during promotion?

On Thu, Mar 19, 2026 at 1:23 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> > I noticed that during standby promotion the startup process sends SIGUSR1 to
> > the slotsync worker to make it exit. Is there a reason for using SIGUSR1?
> > Would it make sense to send SIGTERM instead, so the worker can exit promptly
> > even while waiting?
>
> One consideration here is that we expect all processes to receive
> SIGTERM from init at the beginning of an operating system shutdown
> sequence. Background workers should exit at that point only if their
> services will not be needed during database shutdown. While it
> sounds plausible that a slotsync worker should exit immediately,
> I'm not quite sure if that's what we want.

Currently, when the slotsync worker receives SIGUSR1 during promotion,
it exits at the next interrupt check (i.e., in ProcessSlotSyncInterrupts()).
There's no additional termination handling, so it seems the worker is expected
to exit promptly once the startup process requests it.

Given that, using SIGTERM to make the worker exit immediately seems OK to me...

With the patch, on SIGTERM, the worker basically still exits at the next
interrupt check. The difference is that if it's waiting for input from
the primary (i.e., DoingCommandRead = true), it calls ProcessInterrupts()
in the SIGTERM signal handler (die()) and exits immediately.

Regards.

--
Fujii Masao