Re: Avoid orphaned objects dependencies, take 3

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, Roman Eskin <r(dot)eskin(at)arenadata(dot)io>, Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Avoid orphaned objects dependencies, take 3
Date: 2026-06-09 21:44:10
Message-ID: 0fc145b9b5cf3f59207cf4ca60270448a2891c46.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. With SPI, I bet you can end up in a situation where the
branch fires twice (causing an early reset) or not at all (because the
only call is PROCESS_UTLITY_QUERY).

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).

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-06-09 22:06:38 Re: Add pg_get_publication_ddl function
Previous Message Andres Freund 2026-06-09 21:44:02 Re: libpq maligning postgres stability