RE: Planning counters in pg_stat_statements (using pgss_store)

Поиск
Список
Период
Сортировка
От imai.yoshikazu@fujitsu.com
Тема RE: Planning counters in pg_stat_statements (using pgss_store)
Дата
Msg-id OSBPR01MB461601EA9F13C089C3157E6894FD0@OSBPR01MB4616.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Planning counters in pg_stat_statements (using pgss_store)  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: Planning counters in pg_stat_statements (using pgss_store)  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
Hi Julien,

On Mon, Mar 9, 2020 at 10:32 AM, Julien Rouhaud wrote:
> On Thu, Mar 05, 2020 at 01:26:19PM -0700, legrand legrand wrote:
> > Please consider PG13 shortest path ;o)
> >
> > My one is  parse->queryId != UINT64CONST(0) in pgss_planner_hook().
> > It fixes IVM problem (verified),
> > and keep CTAS equal to pgss without planning counters (verified too).
>
> I still disagree that hiding this problem is the right fix, but since no one
> objected here's a v5 with that behavior.  Hopefully this will be fixed in v14.

Is there any case that query_text will be NULL when executing pg_plan_query?
If query_text will be NULL, we need to add codes to avoid errors in
pgss_store like as current patch. If query_text will not be NULL, we should
add Assert in pg_plan_query so that other developers can notice that they
would not mistakenly set query_text as NULL even without using pgss_planning
counter.

--
Yoshikazu Imai




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: [PATCH] Replica sends an incorrect epoch in its hot standbyfeedback to the Master
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: Berserk Autovacuum (let's save next Mandrill)