On Tue, May 6, 2014 at 12:26 PM, Michael Renner <michael.ren...@amd.co.at> wrote: > 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]
It sounds pretty wonky to me, but then, so does the behavior in the email to which you linked. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
