Message-ID: <0fc145b9b5cf3f59207cf4ca60270448a2891c46.camel@j-davis.com>
Subject: Re: Avoid orphaned objects dependencies, take 3
From: Jeff Davis <pgsql@j-davis.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.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: Tue, 09 Jun 2026 14:44:10 -0700
In-Reply-To: <aie26jMSoEMrHLaI@bdtpg>
References: <afCXPVNuvpf5ECGZ@bdtpg>
	 <CA+TgmobtzkG9HzGtDXbgb3KVE46qHuSvGcuKHgAGQ1aejCoLLw@mail.gmail.com>
	 <agsCqlLTytZCudMv@bdtpg> <aebf583b-b904-4035-a1c1-a4c5ad064dec@iki.fi>
	 <ahYAKgbx05IQdjwR@bdtpg> <3963e573-4852-4d25-b741-7c5c7e1f9140@iki.fi>
	 <ah1PIyqtT+427dWb@bdtpg>
	 <02e28438bd448ff4ee8f6fd78e6b74e657172d73.camel@j-davis.com>
	 <aiLKkTC6QBt8i35P@bdtpg>
	 <71eb9a8835a28165939da567a9d649fe6d21bfa7.camel@j-davis.com>
	 <aie26jMSoEMrHLaI@bdtpg>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.3-0ubuntu1.1 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/0fc145b9b5cf3f59207cf4ca60270448a2891c46.camel%40j-davis.com>
Precedence: bulk

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 =3D=3D 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