MIME-Version: 1.0
References: 
 <CAHGQGwFzNYroAxSoyJhqTU-pH=t4Ej6RyvhVmBZ91Exj_TPMMQ@mail.gmail.com>
 <CAA4eK1+CrQNqiPDKv1wYfdkbX0FARJoi1=0ioaAqkLzbq2vG1w@mail.gmail.com>
 <CAHGQGwHABvuCoyM24HUiFZ5oJq_CoFomjt_cqD-0cJLMjFXJjQ@mail.gmail.com>
 <CAA4eK1LzZGfRANPAnv6NpKCH2ENuZO6HswgY14A=xsOXmucPhw@mail.gmail.com>
 <CABdArM6nepct0uxizCnZqy-kAjjTOndvu7bWtaNcmknuxx82Hg@mail.gmail.com>
 <CAJpy0uBhJB4HqouLXegD=miSkZfZp86tTC2K0K6nf=bHCcsPLQ@mail.gmail.com>
 <CABdArM6Mfhk2+9TVR_D3cgfPWPfHDuZEg7MOc5KqULwt0OcQUg@mail.gmail.com>
 <CAA4eK1+d2vN80-Yvy_Hr=ATF3XL5db+_W-sXF=2Vxm+OFBO82w@mail.gmail.com>
 <CAA4eK1KxU4b53GUor41A55x+Bx-DdOaQ9g1DqURyRY2Cg-hhPQ@mail.gmail.com>
 <CABdArM6pmn5yFqiU33KTYBXYM=Vny2ULnJY_gqFbsMEdt+1dPA@mail.gmail.com>
 <CAHGQGwEsEjXbCthXb02=HScBW7C=BHmygv9SK1VGCcc-9bmTsw@mail.gmail.com>
 <CABdArM5rrhSmFvVL4C5LL0iea-R0HRtB=ZvD=ereoTDa1Tm=NA@mail.gmail.com>
 <CAJpy0uD5brcAOpM8+UGfpzrm4pu-vsSfQUT2zgmcKsXEb8++4Q@mail.gmail.com>
 <CABdArM6E2aBj0FUjr2870sZUQqc6mpV1xSM=sqUFd2tKbfUQHA@mail.gmail.com>
 <TY4PR01MB16907318494FF276465E97DF79453A@TY4PR01MB16907.jpnprd01.prod.outlook.com>
 <CABdArM5RqLna+Y3CF=0BKew-WyxoAKXgcaOnXG1DZpMEiogCqw@mail.gmail.com>
 <CAHGQGwF1=zu478YX1kNaX+qaNp9DH_p+5ZdSfFdTa=JuynJufQ@mail.gmail.com>
 <CABdArM7OsLhyactNNUZ+Wygc_ybv4hhgje9c+h+=PHm3QdS4iQ@mail.gmail.com>
 <CAHGQGwHndKa--mCKAaSpAtdTte_3RJkUueZcDSqdUASqTsDK0Q@mail.gmail.com>
 <CAA4eK1JwVewYZc7eyF9x2-G+Y1ikgU5+a5gmQR+ssft++V51ZA@mail.gmail.com>
 <CAHGQGwHo8f+d3wF-beh6fQnftAkJUyd4mLm2Kg_m41Dg+6dCQQ@mail.gmail.com>
 <CAA4eK1Kb_-zVDcoTP34FZjYcgXAHkUu-vmmGYtH5Tg0o+jW_mQ@mail.gmail.com>
 <CAHGQGwGprr+1ycMFpkni4fOM=CGt7iO1yGnJROHqU59sewV0-Q@mail.gmail.com>
 <CAHGQGwH_AAbtsiYDJt65N7_4PJ0CgOJmBEaCq68e5_tcuG_vXw@mail.gmail.com>
 <CAHGQGwF7QvpRZL6sT3m5EeuacL4SePqmMu1+zJiJc3V2u-tBOA@mail.gmail.com>
In-Reply-To: 
 <CAHGQGwF7QvpRZL6sT3m5EeuacL4SePqmMu1+zJiJc3V2u-tBOA@mail.gmail.com>
From: Nisha Moond <nisha.moond412@gmail.com>
Date: Wed, 8 Apr 2026 15:15:10 +0530
Message-ID: 
 <CABdArM7B8Pnd+pZD201cZ0a1YfzoFytmbQw5XtEb84sD=rM92Q@mail.gmail.com>
Subject: Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during
 promotion?
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
	"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>,
 shveta malik <shveta.malik@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CABdArM7B8Pnd%2BpZD201cZ0a1YfzoFytmbQw5XtEb84sD%3DrM92Q%40mail.gmail.com>
Precedence: bulk

On Wed, Apr 8, 2026 at 12:24=E2=80=AFPM Fujii Masao <masao.fujii@gmail.com>=
 wrote:
>
> On Wed, Apr 8, 2026 at 12:36=E2=80=AFPM Fujii Masao <masao.fujii@gmail.co=
m> wrote:
> > The backpatch added PROCSIG_SLOTSYNC_MESSAGE in the middle of enum
> > ProcSignalReason, which could break the ABI. I=E2=80=99m planning to mo=
ve 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 m=
eaning
> > 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.
>

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.

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.
=E2=80=A6.
  PROCSIG_RECOVERY_CONFLICT_LAST =3D PROCSIG_RECOVERY_CONFLICT_STARTUP_DEAD=
LOCK,
+ PROCSIG_SLOTSYNC_MESSAGE /* ask slot synchronization to stop */
+
NUM_PROCSIGNALS /* Must be last! */
 } ProcSignalReason;

As NUM_PROCSIGNALS increments in both cases, I don=E2=80=99t see any
additional benefit in defining it outside. Thoughts? Happy to be
corrected if I=E2=80=99m missing something.

--
Thanks,
Nisha