Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during promotion? - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during promotion?
Date
Msg-id CAHGQGwF7QvpRZL6sT3m5EeuacL4SePqmMu1+zJiJc3V2u-tBOA@mail.gmail.com
Whole thread
In response to Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during promotion?  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during promotion?
List pgsql-hackers
On Wed, Apr 8, 2026 at 12:36 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> 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?

The patches I'm planning to apply for v17 and v18 are attached.

For v17, I'm still not entirely sure this change is safe from an ABI
perspective. Even if it is, abi-compliance-check may still report
a break since the patch removes NUM_PROCSIGNALS from the enum
(defines it as separate macro). If so, we may need to update
.abi-compliance-history to avoid false positives.

Regards,

--
Fujii Masao

Attachment

pgsql-hackers by date:

Previous
From: Jakub Wartak
Date:
Subject: Failing test_aio tests due to too low(illegal?) segsize_blocks
Next
From: Chao Li
Date:
Subject: Re: Exit walsender before confirming remote flush in logical replication