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