pg_stat_statements: Query normalisation may fail during stats reset

From: Michael Renner <michael(dot)renner(at)amd(dot)co(dot)at>
To: pgsql-hackers(at)postgresql(dot)org
Subject: pg_stat_statements: Query normalisation may fail during stats reset
Date: 2014-05-06 16:26:53
Message-ID: AEE92D38-0A85-459E-B1B8-F647FA00F3EE@amd.co.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-05-06 16:29:57 Re: Sending out a request for more buildfarm animals?
Previous Message Bruce Momjian 2014-05-06 16:22:30 Re: pgindent run