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>
 <CABdArM4a8am4_PYhpse1UwoP2pbh5BzLbTmaePoDMsbFOeJZ-A@mail.gmail.com>
 <CAHGQGwFKULfab1NH1+_-+GdpJ8itUaKGU0_4Uwcr-y0MLZchyQ@mail.gmail.com>
In-Reply-To: 
 <CAHGQGwFKULfab1NH1+_-+GdpJ8itUaKGU0_4Uwcr-y0MLZchyQ@mail.gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Tue, 24 Mar 2026 18:15:41 +0900
Message-ID: 
 <CAHGQGwGETy+7Gv5=6kfYucQUy81SwGQbYr=nftHg7ZeqP07sBA@mail.gmail.com>
Subject: Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during
 promotion?
To: Nisha Moond <nisha.moond412@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/CAHGQGwGETy%2B7Gv5%3D6kfYucQUy81SwGQbYr%3DnftHg7ZeqP07sBA%40mail.gmail.com>
Precedence: bulk

On Tue, Mar 24, 2026 at 3:00=E2=80=AFPM Fujii Masao <masao.fujii@gmail.com>=
 wrote:
>
> On Tue, Mar 24, 2026 at 1:01=E2=80=AFPM Nisha Moond <nisha.moond412@gmail=
.com> wrote:
> > 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 slotsyn=
c worker.
> >
> > 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 for testing!
>
> If you killed the primary with a signal like SIGTERM, an RST packet might=
 have
> been sent to the slotsync worker at that moment. That allowed the worker =
to
> detect the connection loss and exited the wait state, so promotion could
> complete as expected.
>
> To reproduce the issue, you'll need a scenario where the worker cannot de=
tect
> the connection loss. For example, you could block network traffic (e.g., =
with
> iptables) between the primary and the slotsync worker. The key is to crea=
te
> a situation where the worker remains stuck waiting for input for a long t=
ime.

Here's one way to reproduce the issue using iptables:

----------------------------------------------------
[Set up slot synchronization environment]

initdb -D data --encoding=3DUTF8 --locale=3DC
cat <<EOF >> data/postgresql.conf
wal_level =3D logical
synchronized_standby_slots =3D 'physical_slot'
EOF
pg_ctl -D data start
pg_receivewal --create-slot -S physical_slot
pg_recvlogical --create-slot -S logical_slot -P pgoutput
--enable-failover -d postgres
psql -c "CREATE PUBLICATION mypub"

pg_basebackup -D sby1 -c fast -R -S physical_slot -d "dbname=3Dpostgres"
-h 127.0.0.1
cat <<EOF >> sby1/postgresql.conf
port =3D 5433
sync_replication_slots =3D on
hot_standby_feedback =3D on
EOF
pg_ctl -D sby1 start

psql -c "SELECT pg_logical_emit_message(true, 'abc', 'xyz')"


[Block network traffic used by slot synchronization]
su -
iptables -A INPUT -p tcp --sport 5432 -j DROP
iptables -A OUTPUT -p tcp --dport 5432 -j DROP


[Promote the standby]
# wait a few seconds
pg_ctl -D sby1 promote
----------------------------------------------------

In my tests on master, promotion got stuck in this scenario.
With the patch, promotion completed promptly.

After testing, you can remove the network block with:

iptables -D INPUT -p tcp --sport 5432 -j DROP
iptables -D OUTPUT -p tcp --dport 5432 -j DROP

Regards,


--=20
Fujii Masao