Alvaro Herrera writes:
Why not just use an unsigned 64 bit variable? Also, perhaps
palloc_huge() avoids the whole problem in the first place ...
Ja, that crossed my mind too, but the current limit is already far
beyond anything that is usually configured for per-backend memory use,
so I
Piotr Stefaniak writes:
s/int/Size/ doesn't fix anything on 32-bit machines.
Postgres requires twos-complement representation, so that the
assumption that signed integer types wrap around on overflow can be
safely made.
Thanks for the clarification!
--
Sent via pgsql-hackers mailing list
On June 3, 2015 9:42:21 PM GMT+02:00, Andreas Seltenreich
andreas.seltenre...@credativ.de wrote:
Piotr Stefaniak writes:
s/int/Size/ doesn't fix anything on 32-bit machines.
Postgres requires twos-complement representation, so that the
assumption that signed integer types wrap around on
On Thu, Jun 4, 2015 at 1:32 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Andreas Seltenreich wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Andreas Seltenreich andreas.seltenre...@credativ.de writes:
The scary one is due to an integer overflow the attached patch also
fixes.
Andreas Seltenreich wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Andreas Seltenreich andreas.seltenre...@credativ.de writes:
The scary one is due to an integer overflow the attached patch also
fixes.
s/int/Size/ doesn't fix anything on 32-bit machines.
Well, it changes the signedness
Andreas Seltenreich andreas.seltenre...@credativ.de writes:
The scary one is due to an integer overflow the attached patch also
fixes.
s/int/Size/ doesn't fix anything on 32-bit machines.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Tom Lane t...@sss.pgh.pa.us writes:
Andreas Seltenreich andreas.seltenre...@credativ.de writes:
The scary one is due to an integer overflow the attached patch also
fixes.
s/int/Size/ doesn't fix anything on 32-bit machines.
Well, it changes the signedness of the computation on 32-bit, and
