Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id 20210513175107.GF20766@tamriel.snowman.net
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Bruce Momjian <bruce@momjian.us>)
Responses Re: compute_query_id and pg_stat_statements
List pgsql-hackers
Greetings,

* Bruce Momjian (bruce@momjian.us) wrote:
> 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.

Will you be updating pg_upgrade to detect and throw a warning during
check in the event that it discovers a broken config?

If not, then I don't think you're correct in arguing that this need for
additional configuration isn't a valid complaint.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Granting control of SUSET gucs to non-superusers
Next
From: Bruce Momjian
Date:
Subject: Re: compute_query_id and pg_stat_statements