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 CAHGQGwHo8f+d3wF-beh6fQnftAkJUyd4mLm2Kg_m41Dg+6dCQQ@mail.gmail.com
Whole thread Raw
In response to Re: Use SIGTERM instead of SIGUSR1 for slotsync worker to exit during promotion?  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, Apr 2, 2026 at 3:34 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> It is because we added retry slot-sync logic for API in master in
> commit 0d2d4a0ec3eca64e7f5ce7f7630b56a561b2663c. So, there is no
> chance of API waiting except for the race condition being discussed
> here.

Thanks for the info!


> > but it seems we need to backpatch it first before backpatching this patch.
> > Thought?
> >
>
> I feel the use of API before this version was mainly for test-cases as
> it was not production ready. So, it is less helpful to backpatch
> 1362bc33e02, if we want, we can backpatch only the worker part of the
> fix. OTOH, as the issue is not frequent and we have some workaround
> (at least for more common platforms) as well, we can consider not
> backpatching it.

I see your point. OTOH, on second thought, if backpatching commit 1362bc33e02
along with this patch to v17 and v18 *is harmless*, I'd prefer to do so. Keeping
the slotsync shutdown code more consistent across versions would make future
backpatching easier, and selectively backpatching only parts of the shutdown
logic would be more complicated and error-prone. Thought?

Regards,

--
Fujii Masao



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Change default of jit to off
Next
From: John Naylor
Date:
Subject: Re: vectorized CRC on ARM64