Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto)

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto)
Дата
Msg-id 20220218093856.zenl2axicm5mmdc5@jrouhaud
обсуждение исходный текст
Ответ на Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto)  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto)  (Michael Paquier <michael@paquier.xyz>)
Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto)  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Hi,

On Fri, Feb 18, 2022 at 05:22:36PM +0900, Michael Paquier wrote:
>
> So, I have been looking at this problem, and I don't see a problem in
> doing something like the attached, where we add a "regress" mode to
> compute_query_id that is a synonym of "auto". Or, in short, we have
> the default of letting a module decide if a query ID can be computed
> or not, at the exception that we hide its result in EXPLAIN outputs.
>
> Julien, what do you think?

I don't see any problem with that patch.
>
> FWIW, about your question of upthread, I have noticed the behavior
> while testing, but I know of some internal customers that enable
> pg_stat_statements and like doing tests on the PostgreSQL instance
> deployed this way, so that would break.  They are not on 14 yet as far
> as I know.

Are they really testing EXPLAIN output, or just doing application-level tests?



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

Предыдущее
От: "osumi.takamichi@fujitsu.com"
Дата:
Сообщение: RE: logical replication empty transactions
Следующее
От: Christoph Berg
Дата:
Сообщение: Re: pgsql: pg_upgrade: Preserve relfilenodes and tablespace OIDs.