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 12:31:04 +0000
Message-ID: <ailZCCmS0bGlNBfe@bdtpg> (raw)
In-Reply-To: <[email protected]>
References: <agsCqlLTytZCudMv@bdtpg>
	<[email protected]>
	<ahYAKgbx05IQdjwR@bdtpg>
	<[email protected]>
	<ah1PIyqtT+427dWb@bdtpg>
	<[email protected]>
	<aiLKkTC6QBt8i35P@bdtpg>
	<[email protected]>
	<aie26jMSoEMrHLaI@bdtpg>
	<[email protected]>

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.

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: <ailZCCmS0bGlNBfe@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