Hello,
thanks for reviewing the patch! On 09.02.2016 20:32, Christian Ullrich wrote:
- Are there portability issues/Will it work on Windows/BSD etc.:
No, it will not work correctly on Windows when built with MSVC,
although it may work with MinGW.
+++ postgresql-9.5.0/src/backend/tcop/pquery.c
@@ -195,7 +195,7 @@
{
case CMD_SELECT:
snprintf(completionTag, COMPLETION_TAG_BUFSIZE,
- "SELECT %u", queryDesc->estate->es_processed);
+ "SELECT %lu", queryDesc->estate->es_processed);
%lu formats unsigned long. "long" is problematic in terms of
portability, because sizeof(long) is different everywhere. It is 32
bits on Windows and on 32-bit *nix, and 64 bits on 64-bit *nix.
I added the following line to the INSERT formatting in pquery.c:
queryDesc->estate->es_processed += 471147114711LL;
This number is 0x6DB28E70D7; so inserting one row should return
"INSERT 0 2995679448" (0xB28E70D8):
postgres=# insert into t1 values (0);
INSERT 0 2995679448
To fix this, I think it will be enough to change the format strings to
use "%zu" instead of "%lu". pg_snprintf() is selected by configure if
the platform's snprintf() does not support the "z" conversion. I tried
this, and it appears to work:
postgres=# insert into t1 values (0);
INSERT 0 471147114712
I have looked for other uses of "%lu", and found none that may cause
the same issue; apparently they are all used with values that clearly
have 32-bit type; actually, most of them are used to format error
codes in Windows-specific code.
Attached is a new version of the patch, with %lu replaced by %zu.I re-ran all the tests, especially the long test with 2^32+x rows, and it produces the same result as before.
Regards,
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
64bit_4.diff.gz
Description: application/gzip
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
