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

On Mon, Mar 30, 2026 at 1:18 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
> We were using the same log message in two places:
> check_and_set_sync_info() and HandleSlotSyncMessage().
> I think “will not start” fits better in the first case, while “will
> stop” makes sense to keep in the second.

Thanks for updating the patch!

With the patch, in my testing, standby promotion always produces
the following logs:

LOG: replication slot synchronization worker will stop because
promotion is triggered
LOG: replication slot synchronization worker will not start
because promotion was triggered

It looks like the postmaster immediately restarts the slotsync worker after
promotion terminates it, and that new worker then exits on seeing
SlotSyncCtx->stopSignaled.

IMO, always emitting both messages is a bit confusing. It would be nice to
suppress the second one if possible.

One idea would be to prevent the restart altogether. For example,
ProcessSlotSyncMessage() could set SlotSyncCtx->last_start_time to
a special value (like -1), and SlotSyncWorkerCanRestart() could return
false (i.e., prevent postmater from starting up slotsync worker) when
it sees that. Alternatively, SlotSyncWorkerCanRestart() could simply
check SlotSyncCtx->stopSignaled.

That said, as far as I remember correctly, postmaster is generally not
supposed to touch shared memory (per the comments in postmaster.c),
so I'm not sure this approach is acceptable. On the other hand,
postmaster and the slotsync worker already rely on SlotSyncCtx->last_start_time,
so perhaps there's some precedent here.

Regards,

--
Fujii Masao