Re: Fix dropped object handling in pg_event_trigger_ddl_commands

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Sven Klemm <sven(at)timescale(dot)com>
Subject: Re: Fix dropped object handling in pg_event_trigger_ddl_commands
Date: 2021-06-10 08:07:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, Jun 09, 2021 at 09:55:08AM -0400, Alvaro Herrera wrote:
> I'm not sure if we can reasonably implement a fix for older releases.
> I mean, it's a relatively easy test: do a syscache search for the object
> or a catalog indexscan (easy to do with get_object_property_data-based
> API), and if the object is gone, skip getObjectTypeDescription and
> getObjectIdentity. But maybe this is too much code to add to stable
> releases ...

Except that these syscache lookups need to be done on an object-type
basis, which is basically what getObjectDescription() & friends now do
where the logic makes sure that we have a correct objectId <-> cacheId
mapping for the syscache lookups. So that would be roughly copying
into event_trigger.c what objectaddress.c does now, but for the back
branches. It would be better to just backport the changes to support
missing_ok in objectaddress.c if we go down this road, but the
invasiveness makes that much more complicated.

Another thing is that ATExecDropIdentity() does performDeletion() by
using PERFORM_DELETION_INTERNAL, which does not feed the dropped
sequence to pg_event_trigger_dropped_objects(). That feels
inconsistent with CREATE TABLE GENERATED that would feed to event
triggers the CREATE SEQUENCE and ALTER SEQUENCE commands, as well as
ALTER TABLE SET DATA TYPE on a generated column that feeds an internal

An extra idea we could consider, as the drop events are logged before
the other ALTER TABLE subcommands, is to look at the event triggers
registered when the generated sequence is dropped and to erase from
existence any previous events associated to it, but that would make
the logic weak as hell. In all this stuff, simply ignoring the
objects still sounds like a fair and simple course of action to take
if they are gone at the time an event trigger checks after them within
pg_event_trigger_ddl_commands(). Now, this approach makes my spider
sense tingle.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2021-06-10 08:14:57 Re: Fix a few typos in brin_minmax_multi.c
Previous Message Thomas Munro 2021-06-10 07:47:22 Re: A test for replay of regression tests