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:28:21Z
Lists: pgsql-hackers
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/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. 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Avoid orphaned objects dependencies
- 2fbb21170e90 19 (unreleased) landed
- 5100bdbd3ba2 14 (unreleased) landed
- 5fa137727db0 15 (unreleased) landed
- d9bc0d96c247 16 (unreleased) landed
- 3a9909eda207 17 (unreleased) landed
- c8cd3d6976f7 18 (unreleased) landed
-
Don't try to record dependency on a dropped column's datatype
- fd93ee100830 19 (unreleased) landed
- 36b6ed2606e1 14 (unreleased) landed
- ef3d7b15e4cd 15 (unreleased) landed
- d44cd467471c 16 (unreleased) landed
- c1588f92a915 17 (unreleased) landed
- f9d5a52da4ca 18 (unreleased) landed