Re: query_id, pg_stat_activity, extended query protocol - Mailing list pgsql-hackers

From kaido vaikla
Subject Re: query_id, pg_stat_activity, extended query protocol
Date
Msg-id CA+427g9r92sV6PFVsGY7ftR_XqEhhGMVujTyK0v1Y+Pef9jNfA@mail.gmail.com
Whole thread Raw
In response to Re: query_id, pg_stat_activity, extended query protocol  (Michael Paquier <michael@paquier.xyz>)
Responses Re: query_id, pg_stat_activity, extended query protocol
List pgsql-hackers
Thnx.
br
Kaido

On Tue, 13 Jun 2023 at 03:16, Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Jun 12, 2023 at 09:03:24PM +0300, kaido vaikla wrote:
> I have noticed, if query comes from PostgreSQL JDBC Driver, then query_id
> is not present in pg_stat_activity.  Erik Wienhold figured out that reason
> can be in extended query protocol (
> https://www.postgresql.org/message-id/1391613709.939460.1684777418070@office.mailbox.org
> )
> My question is, is it expected or is it a bug: if extended query protocol
> then no query_id  in pg_stat_activity for running query.

Well, you could say a bit of both, I guess.  The query ID is compiled
and stored in backend entries only after parse analysis, which is not
something that would happen when using the execution phase of the
extended query protocol, though it should be possible to access to the
Query nodes in the cached plans and their assigned query IDs.

FWIW, I'd like to think that we could improve the situation, requiring
a mix of calling pgstat_report_query_id() while feeding on some query
IDs retrieved from CachedPlanSource->query_list.  I have not in
details looked at how much could be achieved, TBH.
--
Michael

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Improving FTS for Greek
Next
From: Masahiko Sawada
Date:
Subject: Re: pg_get_indexdef() modification to use TxnSnapshot