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

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Дата
Msg-id 20210319165318.GH3572@momjian.us
обсуждение исходный текст
Ответ на Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Julien Rouhaud <rjuju123@gmail.com>)
Список 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@momjian.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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: [HACKERS] Custom compression methods
Следующее
От: Jacob Champion
Дата:
Сообщение: Re: Proposal: Save user's original authenticated identity for logging