Re: Avoid orphaned objects dependencies, take 3

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Roman Eskin <r(dot)eskin(at)arenadata(dot)io>, Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Avoid orphaned objects dependencies, take 3
Date: 2026-06-04 17:17:57
Message-ID: 44220da166d8f1ef74b2bf76c60a7663dcf9dc07.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Imran Zaheer 2026-06-04 17:29:26 Re: Fix comments to reference xlogrecovery.c
Previous Message Justin Pryzby 2026-06-04 17:14:34 Re: analyze-in-stages post upgrade questions