On 24 May 2012 16:06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I do not want to promise that it's stable over any timeframe longer than
> a server reboot.
You already have though, since pg_stat_statements persistently stores
statistics to disk by default, and can only ever recognise statement
equivalence based on the (dbid, userid, queryid) hash key.
> Aside from the OID dependence problem, we might well
> change the way the hash is calculated in minor releases, for example by
> adding or removing struct fields.
You've already invalidated the saved statistics if you do that, so all
bets are off anyway. If you have to do it, it'll be necessary to bump
PGSS_FILE_HEADER, so that pg_stat_statements will be cleared upon
restart. That will in turn necessitate documenting the issue in the
minor version release notes. I'd hope to avoid that, but it doesn't
seem to me that the situation is made any worse than before by
exposing the value. On the contrary, it could help users to understand
where the problem may have affected them.
If you don't expose the value, users are going to do this sort of
thing anyway, but will be far worse off due to using the query text or
a hash thereof instead of the internal value.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
