Re: [HACKERS] pl/pgSQL, get diagnostics and big data

I wrote: > 2. As I was just complaining to -hackers, plpython plperl and pltcl > all now contain attempts to pass uint64 values (from SPI_processed) > into language-specific functions. We need to figure out whether > that will overflow and whether it's worth doing something about. I fixed this

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

Petr Jelinek writes: > On 12/03/16 04:30, Tom Lane wrote: >> 1. I found two places (marked XXX in this patch) that are using strtoul() >> to parse a tuple count back out of a command tag. That won't do anymore. >> pg_stat_statements has a messy hack for the same problem

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

On 12/03/16 04:30, Tom Lane wrote: 1. I found two places (marked XXX in this patch) that are using strtoul() to parse a tuple count back out of a command tag. That won't do anymore. pg_stat_statements has a messy hack for the same problem (look for HAVE_STRTOULL), which is probably what we

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

I wrote: > I'll take it from here, unless I find bigger issues. Hmm ... so the more I pulled on this string, the more stuff I found. The attached updated patch fixes several additional significant areas: * call_cntr and max_calls in FuncCallContext are now uint64 * Result widths for

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

"Andreas 'ads' Scherbaum" writes: > On 09.02.2016 20:32, Christian Ullrich wrote: >> To fix this, I think it will be enough to change the format strings to >> use "%zu" instead of "%lu". > Attached is a new version of the patch, with %lu replaced by %zu. Nonono ... that

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

* Andreas 'ads' Scherbaum wrote: 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. To paraphrase Twain: "Sire, the Board finds this patch perfect in all the

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

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. +++

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

Ah, so it turns out I should have used the commitfest tool. My apologies; I will send the whole thing through that again. Please disregard the earlier message. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

* Andreas 'ads' Scherbaum wrote: one of our customers approached us and complained, that GET DIAGNOSTICS row_count returns invalid results if the number of rows is > 2^31. It's Attached patch expands the row_count to 64 bit. diagnostics=# select testfunc_pg((2^32 + 5)::bigint);

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, failed Spec compliant: not tested Documentation:not tested * Andreas 'ads' Scherbaum wrote: > one of our customers approached us

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

On 01.02.2016 21:24, Andreas 'ads' Scherbaum wrote: Attached patch expands the row_count to 64 bit. Remembering an issue we had recently with clear text patches, attached is a gzipped version as well. Regards, -- Andreas 'ads' Scherbaum German PostgreSQL

[HACKERS] pl/pgSQL, get diagnostics and big data

Hello, one of our customers approached us and complained, that GET DIAGNOSTICS row_count returns invalid results if the number of rows is > 2^31. It's a bit complicated to test for this case, so I set up a separate instance with this patch, and inserted 2^32+x rows into a table. Internally,