Horton
Menu

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

Fujii Masao <masao.fujii@gmail.com>

View thread
From: Fujii Masao <masao.fujii@gmail.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-03-18T16:05:29Z
Lists: pgsql-hackers

Attachments

Hi,

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?

If the slotsync worker is blocked waiting for input from the primary (e.g.,
due to a network outage between the primary and standby), SIGUSR1 won't
interrupt the wait. As a result, the worker can remain stuck and delay
promotion for a long time.

Would it make sense to send SIGTERM instead, so the worker can exit promptly
even while waiting? I've attached a WIP patch that does this. I haven't updated
the source comments yet, but I can do so if we agree on the approach.

SIGTERM alone is not sufficient, though. A new slotsync worker could start
immediately after the old one exits and block promotion again. To address this,
the patch makes a newly started worker exit immediately if promotion is
in progress.

Thoughts?

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 →

  1. Update .abi-compliance-history for change to enum ProcSignalReason

  2. Fix ABI break by moving PROCSIG_SLOTSYNC_MESSAGE in ProcSignalReason

  3. Fix slotsync worker blocking promotion when stuck in wait

  4. Add retry logic to pg_sync_replication_slots().

  5. Enhance slot synchronization API to respect promotion signal.