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.


                                Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project

Attachment: 64bit_4.diff.gz
Description: application/gzip

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to