MIME-Version: 1.0
References: 
 <CAHGQGwFzNYroAxSoyJhqTU-pH=t4Ej6RyvhVmBZ91Exj_TPMMQ@mail.gmail.com>
 <CAA4eK1+CrQNqiPDKv1wYfdkbX0FARJoi1=0ioaAqkLzbq2vG1w@mail.gmail.com>
 <CAHGQGwHABvuCoyM24HUiFZ5oJq_CoFomjt_cqD-0cJLMjFXJjQ@mail.gmail.com>
In-Reply-To: 
 <CAHGQGwHABvuCoyM24HUiFZ5oJq_CoFomjt_cqD-0cJLMjFXJjQ@mail.gmail.com>
From: Nisha Moond <nisha.moond412@gmail.com>
Date: Tue, 24 Mar 2026 09:31:28 +0530
Message-ID: 
 <CABdArM4a8am4_PYhpse1UwoP2pbh5BzLbTmaePoDMsbFOeJZ-A@mail.gmail.com>
Subject: Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during
 promotion?
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
	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/CABdArM4a8am4_PYhpse1UwoP2pbh5BzLbTmaePoDMsbFOeJZ-A%40mail.gmail.com>
Precedence: bulk

On Mon, Mar 23, 2026 at 11:21=E2=80=AFAM Fujii Masao <masao.fujii@gmail.com=
> wrote:
>
> On Sun, Mar 22, 2026 at 1:52=E2=80=AFAM Amit Kapila <amit.kapila16@gmail.=
com> wrote:
> >
> > On Wed, Mar 18, 2026 at 9:35=E2=80=AFPM Fujii Masao <masao.fujii@gmail.=
com> wrote:
> > >
> > > I noticed that during standby promotion the startup process sends SIG=
USR1 to
> > > the slotsync worker to make it exit. Is there a reason for using SIGU=
SR1?
> > >
> >
> > IIRC, this same signal is used for both the backend executing
> > pg_sync_replication_slots() and slotsync worker. We want the worker to
> > exit and error_out backend. Using SIGTERM for backend could result in
> > its exit.
>
> Why do we want the backend running pg_sync_replication_slots() to throw
> an error here, rather than just exit? If emitting an error is really requ=
ired,
> another option would be to store the process type in SlotSyncCtx and send
> different signals accordingly, for example, SIGTERM for the slotsync work=
er
> and another signal for a backend. But it seems simpler and sufficient to =
have
> the backend exit in this case as well.
>
>
> > Also, we want the last slotsync cycle to complete before
> > promotion so that chances of subscribers that do failover/switchover
> > to new primary has better chances of finding failover slots
> > sync-ready.
>
> I'm not sure how much this behavior helps in failover/switchover scenario=
s.
> But the main issue is that if a primary crash triggers standby promotion,
> that last slotsync cycle can get stuck waiting for input from the primary=
,
> which delays promotion. IOW, failover time can become unnecessarily long
> due to the slotsync worker. I'd like to address that problem.
>

Hi Fujii-san,

I tried reproducing the wait scenario as you mentioned, but could not
reproduce it.
Steps I followed:
1) Place a debugger in the slotsync worker and hold it at
fetch_remote_slots() ... -> libpqsrv_get_result()
2) Kill the primary.
3) Triggered promotion of the standby and release debugger from slotsync wo=
rker.

The slot sync worker stops when the promotion is triggered and then
restarts, but fails to connect to the primary. The promotion happens
immediately.
```
LOG:  received promote request
LOG:  redo done at 0/0301AD40 system usage: CPU: user: 0.00 s, system:
0.02 s, elapsed: 4574.89 s
LOG:  last completed transaction was at log time 2026-03-23
17:13:15.782313+05:30
LOG:  replication slot synchronization worker will stop because
promotion is triggered
LOG:  slot sync worker started
ERROR:  synchronization worker "slotsync worker" could not connect to
the primary server: connection to server at "127.0.0.1", port 9933
failed: Connection refused
Is the server running on that host and accepting TCP/IP connections?
```

I=E2=80=99ll debug this further to understand it better.
In the meantime, please let me know if I=E2=80=99m missing any step, or if =
you
followed a specific setup/script to reproduce this scenario.

--
Thanks,
Nisha