Re: BGWORKER_INTERRUPTIBLE workers are never restarted after DROP/ALTER/CREATE DATABASE

On Sat, Nov 7, 2026 at 4:26 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
>
> On Sat, 07 Nov 2026, Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> > In theory, there seems to be a PID reuse race between finding the workers
> > and sending the signal. But this risk is accepted and considered as too
> > rare in practice to bother in pg_signal_backend() and
> > terminateOtherDBBackends().
>
> Yes, that's why I went with the interrupted flag. I can attach a
> version that terminates them directly instead, if that is acceptable.
> My logic was that if this gets committed before the 19 release, the
> additional flag shouldn't be an issue and it's a better solution.

I don't know. We could either follow the convention or break with it.
There are some discussions & reports related to PID reuse race
[1][2][3][4]. Let's wait and see Michael and others' thoughts on this.

[1] https://www.postgresql.org/message-id/CAFj8pRDZK2zdDgL7b3DS4YEFnfaxcMf7PON1eB1wsor2MauJSA%40mail.gmail.com
[2] https://www.postgresql.org/message-id/CAAZKuFaz7xhiOmUgrYXPEvNLe3aT8y2xpCVVDLQ98SU_4OE76g%40mail.gmail.com
[3] https://www.postgresql.org/message-id/flat/20230208012852.bvkn2am4h4iqjogq%40awork3.anarazel.de
[4] https://www.postgresql.org/message-id/3cf7148a-be17-4fff-9447-a2530590ccd0%40gmail.com

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.