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

On Wed, Apr 8, 2026 at 6:45 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
> Regarding the pg17 change, NUM_PROCSIGNALS is not a process signal
> reason but simply represents the array size, and its value will also
> increase in pg18 (+1) after this backpatch.
> AFAIU, the concern is that extensions might rely on the old compiled
> values of PROCSIG_*, so we should avoid changing their order. However,
> extensions should also not depend on NUM_PROCSIGNALS directly,
> otherwise the pg18 backpatch would pose the same ABI concern. So, it
> seems safe for pg17 as well.
> I also checked core extensions and did not find NUM_PROCSIGNALS being used.

So the question is whether any extensions or third-party code depend on
NUM_PROCSIGNALS. I also couldn't find any such usage, so it seems safe from
an ABI perspective to change its value.


> That said, I think both approaches - adding the new entry at the end
> and defining NUM_PROCSIGNALS outside as done in the patch or adding it
> just before NUM_PROCSIGNALS (like below)  are semantically the same.
> ….
>   PROCSIG_RECOVERY_CONFLICT_LAST = PROCSIG_RECOVERY_CONFLICT_STARTUP_DEADLOCK,
> + PROCSIG_SLOTSYNC_MESSAGE /* ask slot synchronization to stop */
> +
> NUM_PROCSIGNALS /* Must be last! */
>  } ProcSignalReason;
>
> As NUM_PROCSIGNALS increments in both cases, I don’t see any
> additional benefit in defining it outside. Thoughts?

Yes, you're right. So, in v17, I'll just move PROCSIG_SLOTSYNC_MESSAGE to
just before NUM_PROCSIGNALS.

Regards,

--
Fujii Masao