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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers