Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id 20210426170021.GU7629@momjian.us
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: compute_query_id and pg_stat_statements  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Mon, Apr 26, 2021 at 12:56:13PM -0400, Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Bruce Momjian (bruce@momjian.us) wrote:
> >> Techically, pg_stat_statements can turn on compute_query_id when it is
> >> loaded, even if it is 'off' in postgresql.conf, right?  And
> >> pg_stat_statements would know if an alternate hash method is being used,
> >> right?
> 
> > +1 on this approach.
> 
> That'd make it impossible to turn off or adjust afterwards, wouldn't it?
> I'm afraid the confusion stemming from that would outweigh any simplicity.
> 
> I would be in favor of logging a message at startup to the effect of
> "this is misconfigured" (as per upthread discussion), although whether
> people would see that is uncertain.

I think a user-visible warning at CREATE EXNTENSION would help too.

> In the end, it's not like this is the first time we've ever made an
> incompatible change in configuration needs; and it won't be the last
> either.  I don't buy the argument that pg_stat_statements users can't
> cope with adding the additional setting.  (Of course, we should be
> careful to call it out as an incompatible change in the release notes.)

Agreed.

-- 
  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 by date:

Previous
From: Pavel Stehule
Date:
Subject: ERROR: relation "sql_features" does not exist
Next
From: Ondřej Žižka
Date:
Subject: Re: Synchronous commit behavior during network outage