On Thu, Jun 4, 2015 at 1:32 AM, Alvaro Herrera
wrote:
> Andreas Seltenreich wrote:
> > Tom Lane writes:
> >
> > > Andreas Seltenreich 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.
On June 3, 2015 9:42:21 PM GMT+02:00, Andreas Seltenreich
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 overflow can be
>> safely
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
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 dism
Andreas Seltenreich wrote:
> Tom Lane writes:
>
> > Andreas Seltenreich 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
Tom Lane writes:
> Andreas Seltenreich 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 in
combination with the fact that "len" is a
Andreas Seltenreich 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 (pgsql-hackers@postgresql.org)
To make changes to yo
Hi,
when dealing with bytea values that are below the 1GB limit, but too
large to be escaped, the error messages emitted are not very helpful for
users. Especially if they appear in an unrelated context such as during
pg_dump. I've attached a patch that adds ereport()ing that would have
prevente
