On 1 October 2012 17:12, Stephen Frost <sfrost@snowman.net> wrote:
> Peter, all,
>
> * Peter Geoghegan (peter@2ndquadrant.com) wrote:
>> Well, I'll point out once again that the argument about its stability
>> is invalid, because we serialise the entries to disk. If a point
>> release changes the representation of the query tree such that the
>> hash values won't match, then we have no recourse but to bump
>> pg_stat_statements version number, and invalidate all existing
>> entries.
>
> What if we simply included the pg_stat_statements version number in
> what's shown to the user as the 'hash'? ver#.hash ?
That won't really help matters. There'd still be duplicate entries,
from before and after the change, even if we make it immediately
obvious which is which. The only reasonable solution in that scenario
is to bump PGSS_FILE_HEADER, which will cause all existing entries to
be invalidated.
This is a hypothetical scenario, and concerns about it are totally
orthogonal to the actual question of whether or not the queryid should
be exposed...
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
