On 2018-Nov-17, Haribabu Kommi wrote:
> > Okay, but you haven't answered my question:
> > "how is able to remove the correct statement from hash (it seems
> > statement intended to remove 'SELECT $1 AS "ONE"', but it removed
> > 'SELECT $1 + $2 AS "TWO"')"?
>
> I missed to check that question.
>
> SELECT s.queryid FROM pg_stat_statements AS s WHERE s.query =
> 'SELECT $1 AS "ONE"'
>
> With the above query to get the queryid, but there are no such queries
> present in the pg_stat_statements, so the above query returns NULL as
> output, and with NULL as input to the _reset() function, it takes the
> default value of 0, and the reset query compares with rest of the two
> parameters of userid and dbid.
Uh, ouch! Seems to me that this is a high-caliber foot-gun, and will
cause nasty suprises when production stats data disappear inadvertently!
Are you sure we wouldn't like to have this functionality not rely on
NULL values to mean "yeah reset everything!" Seems to me that for safe
production use we would have to tell users to add COALESCE to parameter
values, and it'll be very tedious.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services