On Tue, Oct 3, 2017 at 12:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Geoghegan <pg@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