public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jeff Davis <[email protected]>
To: Bertrand Drouvot <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Roman Eskin <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Alexander Lakhin <[email protected]>
Cc: [email protected]
Cc: Tom Lane <[email protected]>
Subject: Re: Avoid orphaned objects dependencies, take 3
Date: Thu, 18 Jun 2026 16:21:33 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <ajI0Tz9dIJvLGHNY@bdtpg>
References: <[email protected]>
	<aiLKkTC6QBt8i35P@bdtpg>
	<[email protected]>
	<aie26jMSoEMrHLaI@bdtpg>
	<[email protected]>
	<ailZCCmS0bGlNBfe@bdtpg>
	<ail/6I6mcitovsUo@bdtpg>
	<[email protected]>
	<ajEg7PrJYWnmB6zk@bdtpg>
	<[email protected]>
	<ajI0Tz9dIJvLGHNY@bdtpg>

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/[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.

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

view thread (50+ messages)  latest in thread

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Avoid orphaned objects dependencies, take 3
  In-Reply-To: <[email protected]>

* 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