Re: query_id, pg_stat_activity, extended query protocol
От | Michael Paquier |
---|---|
Тема | Re: query_id, pg_stat_activity, extended query protocol |
Дата | |
Msg-id | ZidL90gxA6nAlwQv@paquier.xyz обсуждение исходный текст |
Ответ на | Re: query_id, pg_stat_activity, extended query protocol (Andrei Lepikhov <lepihov@gmail.com>) |
Ответы |
Re: query_id, pg_stat_activity, extended query protocol
Re: query_id, pg_stat_activity, extended query protocol |
Список | pgsql-hackers |
On Tue, Apr 23, 2024 at 11:42:41AM +0700, Andrei Lepikhov wrote: > On 23/4/2024 11:16, Imseih (AWS), Sami wrote: >> + pgstat_report_query_id(linitial_node(Query, psrc->query_list)->queryId, true); >> set_ps_display("BIND"); >> @@ -2146,6 +2147,7 @@ exec_execute_message(const char *portal_name, long max_rows) >> debug_query_string = sourceText; >> pgstat_report_activity(STATE_RUNNING, sourceText); >> + pgstat_report_query_id(portal->queryDesc->plannedstmt->queryId, true); >> cmdtagname = GetCommandTagNameAndLen(portal->commandTag, &cmdtaglen); > > In exec_bind_message, how can you be sure that queryId exists in query_list > before the call of GetCachedPlan(), which will validate and lock the plan? > What if some OIDs were altered in the middle? I am also a bit surprised with the choice of using the first Query available in the list for the ID, FWIW. Did you consider using \bind to show how this behaves in a regression test? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: