Re: pl/pgSQL, get diagnostics and big data

From: Andreas 'ads' Scherbaum <adsmail(at)wars-nicht(dot)de>
To: Christian Ullrich <chris(at)chrullrich(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pl/pgSQL, get diagnostics and big data
Date: 2016-02-10 20:36:46
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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 Content-Type Size
64bit_4.diff.gz application/gzip 1.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-02-10 20:43:08 Re: Optimization for updating foreign tables in Postgres FDW
Previous Message Tom Lane 2016-02-10 20:13:23 Moving responsibility for logging "database system is shut down"