| 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
| 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 |