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