Re: int8 bug on Alpha

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>
Cc: lockhart(at)fourpalms(dot)org, Postgresql <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: int8 bug on Alpha
Date: 2001-03-21 15:47:54
Message-ID: 3AB8CD29.F34F9EA4@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-03-21 15:51:03 New TODO item
Previous Message Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= 2001-03-21 15:12:40 Re: RPM building (was regression on RedHat)