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...@wrigleys.postgresql.org is a similar situation where constants remain unnormalised.
signature.asc
Description: Message signed with OpenPGP using GPGMail
