pg_stat_statements: Query normalisation may fail during stats reset

Поиск
Список
Период
Сортировка
От Michael Renner
Тема pg_stat_statements: Query normalisation may fail during stats reset
Дата
Msg-id AEE92D38-0A85-459E-B1B8-F647FA00F3EE@amd.co.at
обсуждение исходный текст
Ответы Re: pg_stat_statements: Query normalisation may fail during stats reset
Список pgsql-hackers
Hi,

when regularly collecting & resetting query information from pg_stat_statements it’s possible to trigger a situation where unnormalised queries are stored.


I think what happens is the following:

pgss_post_parse_analyse calls pgss_store with a non-null jstate which will cause the query string to be normalised and stored if the query id doesn’t exist in the hash table.


pgss_ExecutorEnd calls pgss_store with a null jstate which will cause the statistics to be stored if the query id exists.

If the query id does not exist (because the hash table has been reset between post_parse_analyse and ExecutorEnd) it hits the entry creation path which in turn will create an entry with the unnormalised query string because jstate is null.


This is a bit counterintuitive if you rely on the query to be normalised, e.g. for privacy reasons where you don’t want to leak query constants like password hashes or usernames.


Is this something that should be fixed or is this intentional behavior? The documentation doesn’t make any strong claims on the state of the query string, so this might be debatable. [1]


best,
Michael

[1] http://www.postgresql.org/message-id/E1UwZTj-00075u-CB@wrigleys.postgresql.org is a similar situation where constants remain unnormalised.
Вложения

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pgindent run
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Sending out a request for more buildfarm animals?