pg_stat_statements: Query normalisation may fail during stats reset - Mailing list pgsql-hackers

From Michael Renner
Subject pg_stat_statements: Query normalisation may fail during stats reset
Date
Msg-id AEE92D38-0A85-459E-B1B8-F647FA00F3EE@amd.co.at
Whole thread Raw
Responses Re: pg_stat_statements: Query normalisation may fail during stats reset  (Robert Haas <robertmhaas@gmail.com>)
List 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.
Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pgindent run
Next
From: Alvaro Herrera
Date:
Subject: Re: Sending out a request for more buildfarm animals?