Re: int8 bug on Alpha

Поиск
Список
Период
Сортировка
От Thomas Lockhart
Тема Re: int8 bug on Alpha
Дата
Msg-id 3AB8CD29.F34F9EA4@alumni.caltech.edu
обсуждение исходный текст
Ответ на int8 bug on Alpha  (Adriaan Joubert <a.joubert@albourne.com>)
Ответы Re: Re: int8 bug on Alpha  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Re: int8 bug on Alpha  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: teg@redhat.com (Trond Eivind Glomsrød)
Дата:
Сообщение: Re: RPM building (was regression on RedHat)
Следующее
От: Bruce Momjian
Дата:
Сообщение: New TODO item