Merlin Moncure writes:
> On Fri, Oct 14, 2016 at 3:31 PM, Tom Lane wrote:
>> Poking around in varbit.c, I noticed some other places that were assuming
>> that a typmod couldn't exceed VARBITMAXLEN.
> Curious -- are there real world scenarios where this would happen?
I think you'd have to be int
On Fri, Oct 14, 2016 at 3:31 PM, Tom Lane wrote:
> Andreas Seltenreich writes:
>> Tom Lane writes:
>>> Seems sane, though I wonder if it'd be better to use -INT_MAX rather
>>> than -VARBITMAXLEN.
>
>> I am undecided between those two. -INT_MAX might be a more precise fix
>> for the problem, but
Andreas Seltenreich writes:
> Tom Lane writes:
>> Seems sane, though I wonder if it'd be better to use -INT_MAX rather
>> than -VARBITMAXLEN.
> I am undecided between those two. -INT_MAX might be a more precise fix
> for the problem, but the extra distance to the danger zone was kind of
> soothi
Tom Lane writes:
>> This is due to an integer overflow in bitshiftright()/bitshiftleft()
>> leading to them recursively calling each other. Patch attached.
>
> Seems sane, though I wonder if it'd be better to use -INT_MAX rather
> than -VARBITMAXLEN.
I am undecided between those two. -INT_MAX m
Andreas Seltenreich writes:
> sqlsmith just found another crasher:
> select bit '1' >> (-2^31)::int;
Nice catch :-)
> This is due to an integer overflow in bitshiftright()/bitshiftleft()
> leading to them recursively calling each other. Patch attached.
Seems sane, though I wonder if it'd b
Hi,
sqlsmith just found another crasher:
select bit '1' >> (-2^31)::int;
This is due to an integer overflow in bitshiftright()/bitshiftleft()
leading to them recursively calling each other. Patch attached.
regards,
Andreas
>From cfdc425f75da268e1c2af08f936c59f34b69e577 Mon Sep 17 00:00:00