Re: int8 bug on Alpha - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: int8 bug on Alpha
Date
Msg-id 3AB8CD29.F34F9EA4@alumni.caltech.edu
Whole thread Raw
In response to int8 bug on Alpha  (Adriaan Joubert <a.joubert@albourne.com>)
Responses Re: Re: int8 bug on Alpha
Re: Re: int8 bug on Alpha
List pgsql-hackers
> > How are you doing the inserts? If you aren't coercing the "2" to be an
> > int8, then (afaik) the math will be done in int4, then upconverted. So,
> > can you confirm that your inserts look like:
> > insert into lint values ('9223372036854775807');
> OK, that was it. I  inserted without quotes. If I insert the quotes it
> works. So why does it work correctly on linux without quotes?

For integers (optional sign and all digits), the code in
src/backend/parser/scan.l uses strtol() to read the string, then checks
for failure. If it fails, the number is interpreted as a double float on
the assumption that if it could hold more digits it would succeed!

Anyway, either strtol() thinks it *should* be able to read a 64 bit
integer, or your machine is silently overflowing. I used to have a bunch
of these boxes, and I recall spending quite a bit of time discovering
that Alphas have some explicit flags which can be set at compile time
which affect run-time detection of floating point and (perhaps) integer
overflow behavior.

Can you check these possibilities? I'd look at strtol() first, then the
overflow/underflow flags second...
                       - Thomas


pgsql-hackers by date:

Previous
From: teg@redhat.com (Trond Eivind Glomsrød)
Date:
Subject: Re: RPM building (was regression on RedHat)
Next
From: Bruce Momjian
Date:
Subject: New TODO item