Re: query_id, pg_stat_activity, extended query protocol

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andrei Lepikhov <lepihov(at)gmail(dot)com>
Cc: "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, kaido vaikla <kaido(dot)vaikla(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: query_id, pg_stat_activity, extended query protocol
Date: 2024-04-23 05:49:43
Message-ID: ZidL90gxA6nAlwQv@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message kuroda.keisuke 2024-04-23 06:44:00 Add privileges test for pg_stat_statements to improve coverage
Previous Message Michael Paquier 2024-04-23 05:42:08 Re: Direct SSL connection with ALPN and HBA rules