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-19T13:36:45Z
Lists: pgsql-hackers
Hi,

On Thu, Jun 18, 2026 at 07:13:38PM -0700, Jeff Davis wrote:
> On Thu, 2026-06-18 at 16:21 -0700, Jeff Davis wrote:
> > IIUC, we cannot have false positives (tracking ACL checks that
> > wouldn't
> > have caused an abort) nor can we have false negatives (missing an ACL
> > check that could cause an abort).
> 
> Idea: what if we check for changes in ACLs on the object, rather than
> whether it passes the check or not?
> 
> Then, if track an ACL check that wouldn't actually cause a failure,
> then it still might be acceptable to throw an error if the ACL changes.
> Still some details to sort out, so this is just an idea.

Yeah, I think I do prefer this idea. As you say, that could cause an error even
if the ACL change does not REVOKE anything on this object (say the ACL change is
a GRANT), but that should be rare in practice and probably much simpler to reason
about that way.

But I don't think tracking ACL changes would be enough though. I think we would
also need to track ROLE changes.

So what about?

- Save a copy of the object's ACL and compare at recheck time: If not the same,
then error out.
- Save the ROLE membership and compare at recheck time. If not the same, then
error out.

That way we cover both parts: the object's ACL and the ROLE membership.

That's just a high level idea, I can move forward and try to implement it.

Thoughts?

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 →
  1. Avoid orphaned objects dependencies

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