agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Roman Eskin <r.eskin@arenadata.io>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Avoid orphaned objects dependencies, take 3
Date: Fri, 19 Jun 2026 13:36:45 +0000
Message-ID: <ajVF7YWf+pxs4cOf@bdtpg> (raw)
In-Reply-To: <b178a9b776897045b8cfe2745bb4f0b178a4ee55.camel@j-davis.com>
References: <aie26jMSoEMrHLaI@bdtpg>
<0fc145b9b5cf3f59207cf4ca60270448a2891c46.camel@j-davis.com>
<ailZCCmS0bGlNBfe@bdtpg>
<ail/6I6mcitovsUo@bdtpg>
<a9eba27eeceebe751490951f0cf631906d4ffd75.camel@j-davis.com>
<ajEg7PrJYWnmB6zk@bdtpg>
<ac52a6aa6be9ccf5cf43c44d009b6e2aa7e2c93d.camel@j-davis.com>
<ajI0Tz9dIJvLGHNY@bdtpg>
<5591d661ea8189f5c057f6b48095f742e0d772f9.camel@j-davis.com>
<b178a9b776897045b8cfe2745bb4f0b178a4ee55.camel@j-davis.com>
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
view thread (93+ messages) latest in thread
Message-ID: <ajVF7YWf+pxs4cOf@bdtpg>
Permalink: ../ajVF7YWf+pxs4cOf@bdtpg/
Also on: postgresql.org/message-id/ajVF7YWf+pxs4cOf@bdtpg
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bertranddrouvot.pg@gmail.com, pgsql@j-davis.com, hlinnaka@iki.fi, robertmhaas@gmail.com, r.eskin@arenadata.io, michael@paquier.xyz, exclusion@gmail.com, tgl@sss.pgh.pa.us
Subject: Re: Avoid orphaned objects dependencies, take 3
In-Reply-To: <ajVF7YWf+pxs4cOf@bdtpg>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox