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

On Sat, Nov 7, 2026 at 9:05 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
>
> 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

An interesting experiment to show that the reuse is real on windows
[1]. But our failure would require timing more than mere PID reuse and
we don't have over 100k machines to run simultaneously...

[1] https://justanothergeek.chdir.org/2020/07/Is-ProcessID-recycling-%EF%B8%8F-on-Windows-over-rated/

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