Re: compute_query_id and pg_stat_statements

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: compute_query_id and pg_stat_statements
Дата
Msg-id 20210513175107.GF20766@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: compute_query_id and pg_stat_statements  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: compute_query_id and pg_stat_statements  (Bruce Momjian <bruce@momjian.us>)
Список 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

Вложения

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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Granting control of SUSET gucs to non-superusers
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: compute_query_id and pg_stat_statements