On Fri, Oct 11, 2013 at 12:19 AM, Daniel Farina <dan...@heroku.com> wrote:
> Probably.
>
> The idea is that without those fields it's, to wit, impossible to
> explain non-monotonic movement in metrics of those queries for precise
> use in tools that insist on monotonicity of the fields, which are all
> cumulative to date I think.
>
> pg_stat_statements_reset() or crashing loses the session, so one
> expects "ncalls" may decrease. In addition, a query that is bouncing
> in and out of the hash table will have its statistics be lost, so its
> statistics will also decrease. This can cause un-resolvable artifact
> in analysis tools.
>
> The two fields allow for precise understanding of when the statistics
> for a given query_id are continuous since the last time a program
> inspected it.
Thanks for elaborating them! Since 'introduced' is reset even when
the statistics is reset, maybe we can do without 'session_start' for
that purpose?
>> + /*
>> + * The role calling this function is unable to see
>> + * sensitive aspects of this tuple.
>> + *
>> + * Nullify everything except the "insufficient privilege"
>> + * message for this entry
>> + */
>> + memset(nulls, 1, sizeof nulls);
>> +
>> + nulls[i] = 0;
>> + values[i] = CStringGetTextDatum("<insufficient privilege>");
>>
>> Why do we need to hide *all* the fields in pg_stat_statements, when
>> it's accessed by improper user? This is a big change of pg_stat_statements
>> behavior, and it might break the compatibility.
>
> It seems like an information leak that grows more major if query_id is
> exposed and, at any point, one can determine the query_id for a query
> text.
So hiding only query and query_id is enough?
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
