Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Date
Msg-id 20210320061234.lvrizayuumvgghgp@nol
Whole thread Raw
In response to Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Mar 19, 2021 at 12:53:18PM -0400, Bruce Momjian wrote:
> 
> Well, given we don't really want to support multiple query id types
> being generated or displayed, the "error out" above should fix it. 
> 
> Let's do this --- tell extensions to error out if the query id is
> already set, either by compute_query_id or another extension.  If an
> extension wants to generate its own query id and store is internal to
> the extension, that is fine, but the server-displayed query id should be
> generated once and never overwritten by an extension.

Agreed, this will ensure that you won't dynamically change the queryid source.

We should also document that changing it requires a restart and calling
pg_stat_statements_reset() afterwards.

v19 adds some changes, plus extra documentation for pg_stat_statements about
the requirement for a queryid to be calculated, and a note that all documented
details only apply for in-core source.  I'm not sure if this is still the best
place to document those details anymore though.

Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.
Next
From: Pavel Stehule
Date:
Subject: Re: pspg pager is finished