Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Hannu Krosing <hannuk(at)google(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Atsushi Torikoshi <atorik(at)gmail(dot)com>, Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Evgeny Efimkin <efimkin(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Date: 2021-03-19 16:53:18
Message-ID: 20210319165318.GH3572@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 19, 2021 at 10:35:21PM +0800, Julien Rouhaud wrote:
> On Fri, Mar 19, 2021 at 02:54:16PM +0100, Hannu Krosing wrote:
> > On Fri, Mar 19, 2021 at 2:29 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > The log-spam could be mitigated by logging it just once per connection
> > the first time it is overridden
>
> Yes, but it might still generate a significant amount of additional lines.
>
> If extensions authors follow the recommendations and only calculate a queryid
> when compute_query_id is off, it shoule be easy to check that you have
> everything setup properly.

Seems extensions that want to generate their own query id should just
error out with a message to the log file if compute_query_id is set ---
that should fix the entire issue --- but see below.

> > Also, we could ask the extensions to expose the "method name" in a read-only GUC
> >
> > so one can do
> >
> > SHOW compute_query_id_method;
> >
> > and get the name of method use
> >
> > compute_query_id_method
> > ------------------------------------
> > builtin
> >
> > And it may even dynamically change to indicate the overriding of builtin
> >
> > compute_query_id_method
> > ---------------------------------------------------
> > fancy_compute_query_id (overrides builtin)
>
> This could be nice, but I'm not sure that it would work well if someones
> install multiple extensions that calculate a queryid (which would be silly but
> still), or load another one at runtime.

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2021-03-19 16:54:10 Re: Proposal: Save user's original authenticated identity for logging
Previous Message Justin Pryzby 2021-03-19 16:35:11 Re: [HACKERS] Custom compression methods