Hi, On Thu, Jun 18, 2026 at 04:21:33PM -0700, Jeff Davis wrote: > On Wed, 2026-06-17 at 05:44 +0000, Bertrand Drouvot wrote: > > > IIUC, this is necessary for correctness. If an ACL failure doesn't > > > cause a transaction abort, then there's a danger that we cause the > > > transaction to fail that should have succeeded. > > > > Exactly, because we'd recheck an "harmless" failed ACL check and then > > produce > > an error. > > > > > So the ACL tracking needs to be precise: we can't track an ACL > > > check > > > unless a failure always causes transaction abort; and we must track > > > an > > > ACL check if it would cause a transaction abort. Right? > > > > I would say: we just need to track (and recheck) ACL checks that > > succeeded. > > 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).
Right. > It's hard for me to convince myself that we got all the cases right; > and if we have, that they won't be broken in the future. > > For instance, I just realized that something else I'm working on is > related: > > https://www.postgresql.org/message-id/[email protected] > > It does an ACL check inside a subtransaction, where the parent > transaction is a DDL statement. It happens to be a DROP statement, so > it's not recording new dependencies, so I don't think it breaks your > tracking mechanism, but it's too close for comfort. I see, I don't think we have this pattern currently but yeah we may have it in the future (and our current tracking mechanism would probably fail in such a case). > We could keep the transaction ID in the tracking record, and ignore > entries from an aborted subxact. But it's getting fairly complex and > delicate. Agreed. We could use RegisterSubXactCallback to save/restore the entry count on subtransaction abort, but as you say it adds complexity. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
