Re: Fix race in background worker termination for database

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "Aya Iwata (Fujitsu)" <iwata(dot)aya(at)fujitsu(dot)com>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: Fix race in background worker termination for database
Date: 2026-07-24 23:10:52
Message-ID: amPw_HbsauFs1h-F@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2026-07-25 01:36:14 Re: Fix publisher-side sequence permission reporting
Previous Message Jacob Brazeal 2026-07-24 21:32:07 Self-join elimination drops an equality qual