Re: Avoid orphaned objects dependencies, take 3

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Cc: 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-04T17:17:57Z
Lists: pgsql-hackers
On Wed, 2026-06-03 at 11:08 -0700, Jeff Davis wrote:
> RangeVarGetRelidExtended() coordinates three things:
> 
>   - name lookup
>   - lock
>   - ACL check
> 
> whereas recheckAclAndLock() only coordinates the latter two.

Given that we don't do another name lookup, the object Oid doesn't
change, and it's not obvious why we need a loop in this path.

A sequence like:

Earlier during DDL processing:
  0. Name lookup and ACL check (and track ACLs)

When recording dependencies:
  1. Lock object
  2. Check that it still exists, error if not
  3. recheck tracked ACLs, error if failure

could work too, right?

I see why you might want to do the checks while not holding the lock,
but it doesn't seem like a requirement (if the user doesn't have
permissions it should fail quickly and release). In any case, it's
worth a comment explaining why the loop is there.

Regards,
	Jeff Davis




Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Avoid orphaned objects dependencies

  2. Don't try to record dependency on a dropped column's datatype