CREATE TABLE/ProcessUtility hook behavior change

From: David Steele <david(at)pgmasters(dot)net>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: CREATE TABLE/ProcessUtility hook behavior change
Date: 2024-04-30 02:26:31
Message-ID: f48ee8e5-0ca1-496b-8914-8f6b2a7e5da3@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hackers,

While testing pgAudit against PG17 I noticed the following behavioral
change:

CREATE TABLE public.test
(
id INT,
name TEXT,
description TEXT,
CONSTRAINT test_pkey PRIMARY KEY (id)
);
NOTICE: AUDIT: SESSION,23,1,DDL,CREATE TABLE,TABLE,public.test,"CREATE
TABLE public.test
(
id INT,
name TEXT,
description TEXT,
CONSTRAINT test_pkey PRIMARY KEY (id)
);",<none>
NOTICE: AUDIT: SESSION,23,1,DDL,ALTER TABLE,TABLE,public.test,"CREATE
TABLE public.test
(
id INT,
name TEXT,
description TEXT,
CONSTRAINT test_pkey PRIMARY KEY (id)
);",<none>
NOTICE: AUDIT: SESSION,23,1,DDL,CREATE
INDEX,INDEX,public.test_pkey,"CREATE TABLE public.test
(
id INT,
name TEXT,
description TEXT,
CONSTRAINT test_pkey PRIMARY KEY (id)
);",<none>

Prior to PG17, ProcessUtility was not being called for ALTER TABLE in
this context. The change probably makes some sense, since the table is
being created then altered to add the primary key, but since it is a
behavioral change I wanted to bring it up.

I attempted a bisect to identify the commit that caused this behavioral
change but pgAudit has been broken since at least November on master and
didn't get fixed again until bb766cde (April 8). Looking at that commit
I'm a bit baffled by how it fixed the issue I was seeing, which was that
an event trigger was firing in the wrong context in the pgAudit tests:

CREATE TABLE tmp (id int, data text);
+ERROR: not fired by event trigger manager

That error comes out of pgAudit itself:

if (!CALLED_AS_EVENT_TRIGGER(fcinfo))
elog(ERROR, "not fired by event trigger manager");

Since bb766cde cannot be readily applied to older commits in master I'm
unable to continue bisecting to find the ALTER TABLE behavioral change.

This seems to leave me with manual code inspection and there have been a
lot of changes in this area, so I'm hoping somebody will know why this
ALTER TABLE change happened before I start digging into it.

Regards,
-David

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Fan 2024-04-30 02:40:54 Re: using extended statistics to improve join estimates
Previous Message Masahiko Sawada 2024-04-30 02:18:14 Re: Fix parallel vacuum buffer usage reporting