MIME-Version: 1.0
References: 
 <CAHGQGwFzNYroAxSoyJhqTU-pH=t4Ej6RyvhVmBZ91Exj_TPMMQ@mail.gmail.com>
 <768857.1773851031@sss.pgh.pa.us>
In-Reply-To: <768857.1773851031@sss.pgh.pa.us>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Thu, 19 Mar 2026 02:10:30 +0900
Message-ID: 
 <CAHGQGwEr_D6kUi-P18siPbaTBGDBumn+nnDdfBtt2=DhExQ+Nw@mail.gmail.com>
Subject: Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during
 promotion?
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAHGQGwEr_D6kUi-P18siPbaTBGDBumn%2BnnDdfBtt2%3DDhExQ%2BNw%40mail.gmail.com>
Precedence: bulk

On Thu, Mar 19, 2026 at 1:23=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Fujii Masao <masao.fujii@gmail.com> writes:
> > I noticed that during standby promotion the startup process sends SIGUS=
R1 to
> > the slotsync worker to make it exit. Is there a reason for using SIGUSR=
1?
> > Would it make sense to send SIGTERM instead, so the worker can exit pro=
mptly
> > 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 expec=
ted
to exit promptly once the startup process requests it.

Given that, using SIGTERM to make the worker exit immediately seems OK to m=
e...

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 =3D true), it calls ProcessInterrupts()
in the SIGTERM signal handler (die()) and exits immediately.

Regards.

--=20
Fujii Masao