Re: Avoid orphaned objects dependencies, take 3

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).

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/5c629d2455946ad2fde3c184f64ea2c323ef2133.camel@j-davis.com

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.

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.

Thoughts?

Regards,
Jeff Davis