Re: pl/pgSQL, get diagnostics and big data
От | Andreas 'ads' Scherbaum |
---|---|
Тема | Re: pl/pgSQL, get diagnostics and big data |
Дата | |
Msg-id | 56BB9F5E.20105@wars-nicht.de обсуждение исходный текст |
Ответ на | Re: pl/pgSQL, get diagnostics and big data (Christian Ullrich <chris@chrullrich.net>) |
Ответы |
Re: pl/pgSQL, get diagnostics and big data
Re: pl/pgSQL, get diagnostics and big data |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: