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 al
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 (look for
>> HAVE_STRTOULL
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 want
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 PortalRunFet
"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 just moves the portabilit
* 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 requiremen
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/tc
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:
http://www.postgresql.org
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 an
* 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);
testfun
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 Us
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,
12 matches
Mail list logo
