Re: Avoid orphaned objects dependencies, take 3
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas <robertmhaas@gmail.com>, Roman Eskin <r.eskin@arenadata.io>, Michael Paquier <michael@paquier.xyz>, Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2026-06-05T13:09:37Z
Lists: pgsql-hackers
Attachments
Hi, On Thu, Jun 04, 2026 at 10:03:22AM -0700, Jeff Davis wrote: > On Mon, 2026-06-01 at 09:21 +0000, Bertrand Drouvot wrote: > > The tracking array lives in a dedicated AclCheckTrackContext memory > > context > > (child of TopMemoryContext). The context is reset at the start of > > each > > top-level utility statement, which frees all prior allocations and > > provides > > clean lifetime management. > > > > Recording is gated by aclcheck_tracking_active, which is set to true > > only > > during top-level utility statement execution. This ensures DML and > > queries pay > > no cost. The flag is cleared both at normal completion of > > ProcessUtility and in > > AbortTransaction to handle the error path. > > This could use some better high-level comments in the code. Something > like: > > "DDL performs ACL checks on referenced objects before acquiring a lock > on them. The lock is acquired much later, when recording dependencies. > Track the ACL checks, so that we can re-check them after acquiring the > lock. Agreed, I just re-worded a bit to add some nuance in v24 attached, as: " may perform ACL checks on referenced objects without first holding a lock on them. In that case, the lock is acquired much later, when recording the dependencies. Track the ACL checks, so that we can re-check them after acquiring the lock while recording dependencies." > XXX: consider refactoring so that we perform the name lookup, > acquire the lock, and check ACLs all in unison, like > RangeVarGetRelidExtended()." I like the XXX, as I agree that what you mentioned in [1] is an area of improvement but not something directly linked to the TOCTOU issue that this patch is addressing. FWIW, with the scenario you described in [1]: - before 2fbb21170e9, the function would be linked to a non existing schema - with 2fbb21170e9, it produces "ERROR: referenced schema was concurrently dropped" the current patch just "keep" the post 2fbb21170e9 behavior. [1]: https://postgr.es/m/5315d15a42109297259d1a3264ad09e363eb98df.camel%40j-davis.com Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Avoid orphaned objects dependencies
- 2fbb21170e90 19 (unreleased) landed
- 5100bdbd3ba2 14 (unreleased) landed
- 5fa137727db0 15 (unreleased) landed
- d9bc0d96c247 16 (unreleased) landed
- 3a9909eda207 17 (unreleased) landed
- c8cd3d6976f7 18 (unreleased) landed
-
Don't try to record dependency on a dropped column's datatype
- fd93ee100830 19 (unreleased) landed
- 36b6ed2606e1 14 (unreleased) landed
- ef3d7b15e4cd 15 (unreleased) landed
- d44cd467471c 16 (unreleased) landed
- c1588f92a915 17 (unreleased) landed
- f9d5a52da4ca 18 (unreleased) landed