Re: Fix race in background worker termination for database

> On Jul 25, 2026, at 07:10, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Fri, Jul 24, 2026 at 01:32:05PM +0000, Aya Iwata (Fujitsu) wrote:
>> I'm not sure how long the PGPROC might be reused or modified after it is
>> retrieved, but it's true that the scenario you're describing could occur
>> depending on the timing.
>>
>> I think this fix looks good. I would appreciate hearing what the other members think.
>
> Hmm. The case of an interruptible bgworker terminating itself between
> the moment BackendPidGetProc() is called and the moment we read the
> databaseId, meaning that the PGPROC entry gets cleaned with the same
> proc entry being reused afterwards? Say (not tested myself, just
> hand-waving for now):
> - Call BackendPidGetProc()
> - Hold a breakpoint with the proc pointer to enlarge the window.
> - Manipulate the PGPROC slots and change a databaseId.
> - Terminate incorrect database.
>
> That would warrant a WithLock() call with a procarray lock held until
> we check the contents of the procarray entry.

Thanks for confirming.

> Keeping the DEBUG2
> inside or outside the LWLock does not matter much, that's a LWLock we
> talk about, not a spinlock.
> --
> Michael

Okay, I was being overly cautious.

PFA v2:

* Moved elog() into the lock section and removed the now-unneeded local variable “terminate".
* Incorporated Haibo’s suggestion to copy slot->pid before acquiring the lock.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/