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