Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Дата
Msg-id 4157148.1602865409@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> In this case, I suppose using pg_stat_statement would require to have it
> enabled, and it'd just not collect anything if disabled.

Alternatively, pg_stat_statement might be able to force it on
(applying a non-overridable PGC_INTERNAL-level setting) on load?
Not sure if that'd be desirable or not.

If the behavior of pg_stat_statement is to do nothing when it
sees a query without the ID calculated (which I guess it'd have to)
then there's a potential security issue if the GUC is USERSET level:
a user could hide her queries from pg_stat_statement by turning the
GUC off.  So this line of thought suggests the GUC needs to be at
least SUSET, and maybe higher ... doesn't pg_stat_statement need it
to have the same value cluster-wide?

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Sometimes the output to the stdout in Windows disappears
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?