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 20210513174115.GN11075@momjian.us
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Stephen Frost <sfrost@snowman.net>)
Responses Re: compute_query_id and pg_stat_statements
List pgsql-hackers
On Thu, May 13, 2021 at 01:33:27PM -0400, Stephen Frost wrote:
> I'm coming around to have a similar feeling.  While having an
> alternative query ID might be useful, I have a hard time seeing it as
> likely to be a hugely popular feature that is worth a lot of users
> complaining (as we've seen already, multiple times, before even getting
> to beta...) that things aren't working anymore.  That we can't figure
> out which libraries to load automatically based on what extensions have
> been installed and therefore make everyone have to change
> shared_preload_libraries isn't a good thing and requiring additional
> configuration for extremely common extensions like pg_stat_statements is
> making it worse.

Would someone please explain what is wrong with what is in the tree
now, except that it needs additional warnings about misconfiguration? 
Requiring two postgresql.conf changes instead of one doesn't seem like a
valid complaint to me, especially if the warnings are in place and the
release notes mention it.

-- 
  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: Christoph Berg
Date:
Subject: Re: compute_query_id and pg_stat_statements
Next
From: Stephen Frost
Date:
Subject: Re: Granting control of SUSET gucs to non-superusers