On Wed, Apr 8, 2026 at 6:45 PM Nisha Moond <[email protected]> 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
