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: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>,
shveta malik <shveta.malik@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-01T09:48:59Z
Lists: pgsql-hackers
On Wed, Apr 1, 2026 at 2:34 PM Nisha Moond <nisha.moond412@gmail.com> wrote: > > On Tue, Mar 31, 2026 at 3:56 PM Zhijie Hou (Fujitsu) > <houzj.fnst@fujitsu.com> wrote: > > > > On Tuesday, March 31, 2026 2:02 PM Nisha Moond <nisha.moond412@gmail.com> wrote: > > > > > > > > > Please find the updated patch (v6) attached. > > > > Thanks for updating the patch. One minor comment: > > > > I think we could avoid interrupting and reporting an ERROR when > > IsSyncingReplicationSlots() returns false to avoid reporting ERROR unnecessarily > > when the slotsync has already finished. > > > > Thanks for the review. Fixed above in v7. Thanks for updating the patch! It looks good to me, with just a few minor points . If those are addressed, I'd like to push it. + * a new worker (or a new API call) that starts after the old worker was "API" feels a bit vague. It might be clearer to explicitly say "pg_sync_replication_slots()". + PROCSIG_SLOTSYNC_MESSAGE, /* ask slotsync worker/API to stop */ "API" here also feels a bit vague. So I'd like to use "ask slot synchronization to stop" as the comment, instead. + * We cannot rely solely on 'stopSignaled' here because: + * 1) It resides in shared memory and is visible to all processes, so checking + * it directly in ProcessInterrupts() would require additional checks to + * ensure only the synchronizing process acts on it. + * 2) It has different lifetime semantics and cannot be reset after handling, + * as it also guards against postmaster and promotion race conditions. + * 3) Accessing it requires acquiring a spinlock, which can be too expensive + * or undesirable for every ProcessInterrupts() call. Now that PROCSIG_SLOTSYNC_MESSAGE is in place, using SlotSyncShutdownPending is intuitive. So it seems more useful to explain why stopSignaled is still needed rather than why SlotSyncShutdownPending is used (i.e., why stopSignaled is not sufficient). Since that rationale is already covered in the SlotSyncCtx comments, I'd suggest removing this comment block. As for backpatching, this looks like it should go back to v17, where slotsync was introduced. Thought? 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