Has anyone seen this SPARC bug? [Fwd: Bug#165060: postgresql: int8 value out of range on sparc]
This is a Debian bug report from a SPARC user. It doesn't happen for me
on i386 7.2.3.
Can anyone reproduce it or suggest a reason for it?
-----Forwarded Message-----
From: Brian Macy <bmacy@macykids.net>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#165060: postgresql: int8 value out of range on sparc
Date: 16 Oct 2002 09:46:46 -0700
Package: postgresql
Version: 7.2.3-0.1
Severity: grave
Tags: sid upstream
Justification: renders package unusable
Only excepts 32bit values and not 64bit. Endian issue?
This is on sparc.
com.pany=# create table foo (val bigint);
CREATE
com.pany=# insert into foo values (1034784236789);
ERROR: Floating point conversion to int8 is out of range
com.pany=# insert into foo values (103478423678);
ERROR: Floating point conversion to int8 is out of range
com.pany=# insert into foo values (10347842367);
ERROR: Floating point conversion to int8 is out of range
com.pany=# insert into foo values (1034784236);
INSERT 16872 1
I also got this on a restore with inserts from a remote machine.
psql:restore.sql:124576: ERROR: int8 value out of range:
"1033219132976"
psql:restore.sql:124577: ERROR: int8 value out of range:
"1033217951899"
psql:restore.sql:124578: ERROR: int8 value out of range:
"1033220352916"
psql:restore.sql:124579: ERROR: int8 value out of range:
"1033217955384"
Brian Macy
-- System Information:
Debian Release: testing/unstable
Architecture: sparc
Kernel: Linux boaz 2.4.19 #1 SMP Sat Oct 5 16:03:12 EDT 2002 sparc64
Locale: LANG=C, LC_CTYPE=C
Versions of packages postgresql depends on:
ii adduser 3.48 Add and remove users and groups
ii debianutils 1.16.6 Miscellaneous utilities specific t
ii libc6 2.2.5-15 GNU C Library: Shared libraries an
ii libpam0g 0.76-6 Pluggable Authentication Modules l
ii libpgsql2 7.2.3-0.1 Shared library libpq.so.2 for Post
ii libreadline4 4.3-4 GNU readline and history libraries
ii libssl0.9.6 0.9.6g-9 SSL shared libraries
ii postgresql-client 7.2.3-0.1 Front-end programs for PostgreSQL
ii procps 1:3.0.3-1 The /proc file system utilities.
ii python2.2 2.2.2-1 An interactive object-oriented scr
ii zlib1g 1:1.1.4-6 compression library - runtime
-- no debconf information
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight, UK
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"But be ye doers of the word, and not hearers only,
deceiving your own selves." James 1:22
On Wednesday 16 October 2002 05:51 pm, Oliver Elphick wrote:
This is a Debian bug report from a SPARC user. It doesn't happen for me
on i386 7.2.3.
Can anyone reproduce it or suggest a reason for it?
I can't reproduce this on Aurora SPARC Linux with the RPM install.
System is a SPARCification of Red Hat 7.3 -- gcc 2.96, glibc 2.2.5, kernel
2.4.18-1.000sparc, Aurora build 0.42.
----Session-excerpt-------
bash-2.05a$ createdb test
CREATE DATABASE
bash-2.05a$ psql test
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
test=# create table foo (val bigint);
CREATE
test=# insert into foo values (1034784236789);
INSERT 16563 1
test=# select * from foo;
val
---------------
1034784236789
(1 row)
test=#
---------------------------
System this was tested on:
bash-2.05a$ uname -a
Linux dev.ramifordistat.net 2.4.18-1.000sparc #1 Mon Sep 30 21:14:57 EDT 2002
sparc64 unknown
bash-2.05a$
This is an Ultra 5/333 with 128MB RAM.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Oliver Elphick <olly@lfix.co.uk> writes:
This is a Debian bug report from a SPARC user. It doesn't happen for me
on i386 7.2.3.
com.pany=# insert into foo values (1034784236789);
ERROR: Floating point conversion to int8 is out of range
I'm betting that rint() is broken on this platform. It would be useful
to trace through the execution of dtoi8() (in src/backend/utils/adt/int8.c)
to see exactly why it's spitting up.
regards, tom lane
This is fixed by building the Debian package without the --with-openssl
flag passed into configure. I don't have time to look into it at the
moment but doing a `./configure --with-openssl` has the side effect of
no native 64bit type being found.
Brian Macy
Oliver Elphick wrote:
Show quoted text
This is a Debian bug report from a SPARC user. It doesn't happen for me
on i386 7.2.3.Can anyone reproduce it or suggest a reason for it?
-----Forwarded Message-----
From: Brian Macy <bmacy@macykids.net>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#165060: postgresql: int8 value out of range on sparc
Date: 16 Oct 2002 09:46:46 -0700Package: postgresql
Version: 7.2.3-0.1
Severity: grave
Tags: sid upstream
Justification: renders package unusableOnly excepts 32bit values and not 64bit. Endian issue?
This is on sparc.
com.pany=# create table foo (val bigint);
CREATE
com.pany=# insert into foo values (1034784236789);
ERROR: Floating point conversion to int8 is out of range
com.pany=# insert into foo values (103478423678);
ERROR: Floating point conversion to int8 is out of range
com.pany=# insert into foo values (10347842367);
ERROR: Floating point conversion to int8 is out of range
com.pany=# insert into foo values (1034784236);
INSERT 16872 1I also got this on a restore with inserts from a remote machine.
psql:restore.sql:124576: ERROR: int8 value out of range:
"1033219132976"
psql:restore.sql:124577: ERROR: int8 value out of range:
"1033217951899"
psql:restore.sql:124578: ERROR: int8 value out of range:
"1033220352916"
psql:restore.sql:124579: ERROR: int8 value out of range:
"1033217955384"Brian Macy
-- System Information:
Debian Release: testing/unstable
Architecture: sparc
Kernel: Linux boaz 2.4.19 #1 SMP Sat Oct 5 16:03:12 EDT 2002 sparc64
Locale: LANG=C, LC_CTYPE=CVersions of packages postgresql depends on:
ii adduser 3.48 Add and remove users and groups
ii debianutils 1.16.6 Miscellaneous utilities specific t
ii libc6 2.2.5-15 GNU C Library: Shared libraries an
ii libpam0g 0.76-6 Pluggable Authentication Modules l
ii libpgsql2 7.2.3-0.1 Shared library libpq.so.2 for Post
ii libreadline4 4.3-4 GNU readline and history libraries
ii libssl0.9.6 0.9.6g-9 SSL shared libraries
ii postgresql-client 7.2.3-0.1 Front-end programs for PostgreSQL
ii procps 1:3.0.3-1 The /proc file system utilities.
ii python2.2 2.2.2-1 An interactive object-oriented scr
ii zlib1g 1:1.1.4-6 compression library - runtime-- no debconf information
Oliver Elphick <olly@lfix.co.uk> writes:
This is a Debian bug report from a SPARC user. It doesn't happen
for me
on i386 7.2.3.
com.pany=# insert into foo values (1034784236789);
ERROR: Floating point conversion to int8 is out of range
I'm betting that rint() is broken on this platform. It would be
useful to trace through the execution of dtoi8() (in
src/backend/utils/adt/int8.c) to see exactly why it's spitting up.
The problem is that libcrypto.so has an unresolved symbol on Debian
and this is making the "long long int is 64bit" test fail in configure
fail, so it thinks long long is not 64bit. (So the only difference
between this and a correct build is that HAVE_LONG_LONG_INT_64 is not
defined.)
I don't know if this is the way postgresql is supposed to behave on
platforms with no 64-bit integer; if not, there is a postgresql bug
here.
Also, I'm not sure if the "upgrade the database to a new version"
scripts are from the Debian package or upstream, but it looks like
they need more error checking. (Brian tells me that it bailed on
most of the data inserts, but claimed that everything went ok.)
Steve
dunham@cse.msu.edu
Import Notes
Resolved by subject fallback
Steve Dunham <dunham@cse.msu.edu> writes:
Oliver Elphick <olly@lfix.co.uk> writes:
com.pany=# insert into foo values (1034784236789);
ERROR: Floating point conversion to int8 is out of range
The problem is that libcrypto.so has an unresolved symbol on Debian
and this is making the "long long int is 64bit" test fail in configure
fail, so it thinks long long is not 64bit.
Ah so.
I don't know if this is the way postgresql is supposed to behave on
platforms with no 64-bit integer; if not, there is a postgresql bug
here.
No, that is the expected behavior: "int8" is effectively int4, and so
the above value in fact is out of range for "int8".
regards, tom lane