On Tue, Oct 3, 2017 at 12:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Peter Geoghegan <p...@bowt.ie> writes: > > You need to change the SQL interface as well, although I'm not sure > > exactly how. The problem is that you are now passing a uint64 queryId > > to Int64GetDatumFast() within pg_stat_statements_internal(). That > > worked when queryId was a uint32, because you can easily represent > > values <= UINT_MAX as an int64/int8. However, you cannot represent the > > second half of the range of uint64 within a int64/int8. I think that > > this will behave different depending on USE_FLOAT8_BYVAL, if nothing > > else. > > Maybe intentionally drop the high-order bit, so that it's a 63-bit ID? > +1, I see 3 options there: 1) Drop high-order bit, as you proposed. 2) Allow negative queryIds. 3) Implement unsigned 64-type. #1 causes minor loss of precision which looks rather insignificant in given context. #2 might be rather unexpected for users whose previously had non-negative queryIds. Changing queryId from 32-bit to 64-bit itself might require some adoption from monitoring software. But queryIds are user-visible, and negative queryIds would look rather nonlogical. #3 would be attaching hard and long-term problem by insufficient reason. Thus, #1 looks like most harmless solution. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
