public inbox for [email protected]  
help / color / mirror / Atom feed
From: Bertrand Drouvot <[email protected]>
To: Jeff Davis <[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: Wed, 10 Jun 2026 15:16:56 +0000
Message-ID: <ail/6I6mcitovsUo@bdtpg> (raw)
In-Reply-To: <ailZCCmS0bGlNBfe@bdtpg>
References: <[email protected]>
	<ahYAKgbx05IQdjwR@bdtpg>
	<[email protected]>
	<ah1PIyqtT+427dWb@bdtpg>
	<[email protected]>
	<aiLKkTC6QBt8i35P@bdtpg>
	<[email protected]>
	<aie26jMSoEMrHLaI@bdtpg>
	<[email protected]>
	<ailZCCmS0bGlNBfe@bdtpg>

Hi,

On Wed, Jun 10, 2026 at 12:31:04PM +0000, Bertrand Drouvot wrote:
> Hi,
> 
> On Tue, Jun 09, 2026 at 02:44:10PM -0700, Jeff Davis wrote:
> > Hi,
> > 
> > On Tue, 2026-06-09 at 06:47 +0000, Bertrand Drouvot wrote:
> > > In order to be on the safe side of things, the attached now iterates
> > > through all
> > > matching entries (and not only the last one).
> > 
> > I don't think:
> > 
> >   if (context == PROCESS_UTILITY_TOPLEVEL)
> > 
> > is quite right.
> > 
> > In any case, I don't think mixing the tracking entries between entirely
> > different DDL commands is a good idea. If you execute DDL inside of SPI
> > in its own subtransaction, and it inserts a tracking entry to recheck
> > something, and then you roll back the subxact, you don't want the
> > tracking entry to then cause the outer transaction to fail. I didn't
> > test this, so if there's something preventing this kind of problem, let
> > me know.
> > 
> > We probably need to track where we are in the stack of ProcessUtility()
> > calls and keep the tracking entries separate, and always remove entries
> > from that level on return (or rollback).
> 
> I think you are right. I changed this in the attached so that aclcheck_tracked_count
> is saved on entry and restored on return of each ProcessUtility call, so that each
> nesting level's entries are kept separate.
> 
> Also, the reset is now done whenever tracking is initialized (means at the
> outermost ProcessUtility call that starts tracking).
> 
> I think that addresses your concerns and it also fixes the issues reported
> by the cfbot (that I mentioned up-thread).
> 
> I also added more tests related to nested calls.

PFA a new version of v26, it adds a new test as compared to the v26 previously
shared.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com


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: <ail/6I6mcitovsUo@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