Re: compute_query_id and pg_stat_statements

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

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