CREATE TABLE/ProcessUtility hook behavior change - Mailing list pgsql-hackers

From David Steele
Subject CREATE TABLE/ProcessUtility hook behavior change
Date
Msg-id f48ee8e5-0ca1-496b-8914-8f6b2a7e5da3@pgmasters.net
Whole thread Raw
Responses Re: CREATE TABLE/ProcessUtility hook behavior change
List 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



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Fix parallel vacuum buffer usage reporting
Next
From: Andy Fan
Date:
Subject: Re: using extended statistics to improve join estimates