Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during promotion?
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Nisha Moond <nisha.moond412@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-03-24T06:00:20Z
Lists: pgsql-hackers
On Tue, Mar 24, 2026 at 1:01 PM 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 slotsync 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’ll debug this further to understand it better. > In the meantime, please let me know if I’m 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 detect 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 create a situation where the worker remains stuck waiting for input for a long time. Regards, -- Fujii Masao
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Update .abi-compliance-history for change to enum ProcSignalReason
- 29d8bd908560 17.10 landed
-
Fix ABI break by moving PROCSIG_SLOTSYNC_MESSAGE in ProcSignalReason
- 586f4266fb49 17.10 landed
- acf49bfede2a 18.4 landed
-
Fix slotsync worker blocking promotion when stuck in wait
- 15910b1c363f 17.10 landed
- 58c1188a3eaa 18.4 landed
- db93032a7cbd 19 (unreleased) landed
-
Add retry logic to pg_sync_replication_slots().
- 0d2d4a0ec3ec 19 (unreleased) cited
-
Enhance slot synchronization API to respect promotion signal.
- 1362bc33e025 19 (unreleased) cited