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
|
Список | 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 по дате отправления: