CREATE TABLE/ProcessUtility hook behavior change

Поиск
Список
Период
Сортировка
От David Steele
Тема CREATE TABLE/ProcessUtility hook behavior change
Дата
Msg-id f48ee8e5-0ca1-496b-8914-8f6b2a7e5da3@pgmasters.net
обсуждение исходный текст
Ответы Re: CREATE TABLE/ProcessUtility hook behavior change  (jian he <jian.universality@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Fix parallel vacuum buffer usage reporting
Следующее
От: Andy Fan
Дата:
Сообщение: Re: using extended statistics to improve join estimates