> On Jul 25, 2026, at 07:10, Michael Paquier <[email protected]> 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/
v2-0001-Protect-PGPROC-lookup-when-terminating-background.patch
Description: Binary data
