Re: pg_stat_statements: Query normalisation may fail during stats reset

On Tue, May 6, 2014 at 12:26 PM, Michael Renner
<michael(dot)renner(at)amd(dot)co(dot)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