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

Reply via email to