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
