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

On Wed, Apr 8, 2026 at 11:39 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Tue, Apr 7, 2026 at 12:48 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > I agree with this line of reasoning here or in general as well but
> > personally I am a bit hesitant to back patch changes which are not
> > mandatory. In this particular case, I don't see any problem with
> > backpatching the part of code you want to backpatch, so I leave it to
> > your judgement.
>
> Thanks for the comment!
>
> I decided to backpatch commit 1362bc33e02. Although pg_sync_replication_slots()
> lacks retry logic in v17 and v18 and is therefore less likely to block
> promotion, the issue still exists in those versions.
>
> Given that, it seemed worthwhile to backpatch the change and fix cases where
> both the slotsync worker and pg_sync_replication_slots() can block promotion
> when stuck in a wait.
>
> I've pushed and backpatched the patch. Thanks!

The backpatch added PROCSIG_SLOTSYNC_MESSAGE in the middle of enum
ProcSignalReason, which could break the ABI. I’m planning to move it to
the end of the enum in v17 and v18.

That seems to work for v18. However, in v17, NUM_PROCSIGNALS is defined
as the last enum value:

NUM_PROCSIGNALS /* Must be last! */
} ProcSignalReason;

So simply moving PROCSIG_SLOTSYNC_MESSAGE to the end would change the meaning
of NUM_PROCSIGNALS.

One option might be to remove NUM_PROCSIGNALS from the enum, move
PROCSIG_SLOTSYNC_MESSAGE to the end, and define it separately, e.g.
#define NUM_PROCSIGNALS (PROCSIG_SLOTSYNC_MESSAGE + 1). Would that
be acceptable without breaking the ABI? Thoughts?

Regards,

--
Fujii Masao