Pg 7.2.3 int8 value out of range
Only excepts 32bit values and not 64bit. Endian issue?
This is on sparc linux.
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
Brian Macy <bmacy@macykids.net> writes:
Only excepts 32bit values and not 64bit. Endian issue?
This is on sparc linux.
Hmm, did configure find any working 64bit int type? Let's see this part
of your src/include/pg_config.h file:
/* Set to 1 if type "long int" works and is 64 bits */
/* #undef HAVE_LONG_INT_64 */
/* Set to 1 if type "long long int" works and is 64 bits */
#define HAVE_LONG_LONG_INT_64
/* Set to 1 if type "long long int" constants should be suffixed by LL */
#define HAVE_LL_CONSTANTS 1
/* Define this as the appropriate snprintf format for 64-bit ints, if any */
#define INT64_FORMAT "%lld"
regards, tom lane
On Thursday 17 October 2002 09:28 pm, Tom Lane wrote:
Brian Macy <bmacy@macykids.net> writes:
Only excepts 32bit values and not 64bit. Endian issue?
This is on sparc linux.
Specifically Debian. Aurora SPARC Linux does not suffer from this problem.
On Aurora, the userland is 32 bit -- is it possible Debian has a 64 bit
userland? As I detailed in my previous email on this subject, I cannot
reproduce the problem on Aurora SPARC Linux build 0.42, which is based on Red
Hat 7.3.
Hmm, did configure find any working 64bit int type? Let's see this part
of your src/include/pg_config.h file:
/* Set to 1 if type "long int" works and is 64 bits */
/* #undef HAVE_LONG_INT_64 */
/* Set to 1 if type "long long int" works and is 64 bits */
#define HAVE_LONG_LONG_INT_64
/* Set to 1 if type "long long int" constants should be suffixed by LL */
#define HAVE_LL_CONSTANTS 1
/* Define this as the appropriate snprintf format for 64-bit ints, if any
*/ #define INT64_FORMAT "%lld"
For Aurora, those lines, along with some others, are:
/* Set to 1 if type "long int" works and is 64 bits */
/* #undef HAVE_LONG_INT_64 */
/* Set to 1 if type "long long int" works and is 64 bits */
#define HAVE_LONG_LONG_INT_64
/* Set to 1 if type "long long int" constants should be suffixed by LL */
#define HAVE_LL_CONSTANTS 1
/* Define this as the appropriate snprintf format for 64-bit ints, if any */
#define INT64_FORMAT "%lld"
/*
* We need a #define symbol for sizeof(Datum) for use in some #if tests.
*/
#define SIZEOF_DATUM 4
/*
* These must be defined as the alignment requirement (NOT the size) of
* each of the basic C data types (except char, which we assume has align 1).
* MAXIMUM_ALIGNOF is the largest alignment requirement for any C data type.
* ALIGNOF_LONG_LONG_INT need only be defined if HAVE_LONG_LONG_INT_64 is.
*/
#define ALIGNOF_SHORT 2
#define ALIGNOF_INT 4
#define ALIGNOF_LONG 4
#define ALIGNOF_LONG_LONG_INT 8
#define ALIGNOF_DOUBLE 8
#define MAXIMUM_ALIGNOF 8
This was built with the RPM spec file using the 'sparc32' utility that builds
the sun4 32bit userland executables.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Debian is 32bit user land.
boaz:~# file /usr/lib/postgresql/bin/postgres
/usr/lib/postgresql/bin/postgres: ELF 32-bit MSB executable, SPARC,
version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared
libs), stripped
Since it is debian it's prebuilt but i'll try building it myself....
boaz:~/postgresql-7.2.3# gcc -v
Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
From src/lib/pg_config.h
/* Set to 1 if type "long int" works and is 64 bits */
/* #undef HAVE_LONG_INT_64 */
/* Set to 1 if type "long long int" works and is 64 bits */
/* #undef HAVE_LONG_LONG_INT_64 */
/* Set to 1 if type "long long int" constants should be suffixed by LL */
/* #undef HAVE_LL_CONSTANTS */
/* Define this as the appropriate snprintf format for 64-bit ints, if any */
#define INT64_FORMAT "%ld"
/*
* We need a #define symbol for sizeof(Datum) for use in some #if tests.
*/
#define SIZEOF_DATUM 4
Brian Macy
Lamar Owen wrote:
Show quoted text
On Thursday 17 October 2002 09:28 pm, Tom Lane wrote:
Brian Macy <bmacy@macykids.net> writes:
Only excepts 32bit values and not 64bit. Endian issue?
This is on sparc linux.Specifically Debian. Aurora SPARC Linux does not suffer from this problem.
On Aurora, the userland is 32 bit -- is it possible Debian has a 64 bit
userland? As I detailed in my previous email on this subject, I cannot
reproduce the problem on Aurora SPARC Linux build 0.42, which is based on Red
Hat 7.3.Hmm, did configure find any working 64bit int type? Let's see this part
of your src/include/pg_config.h file:/* Set to 1 if type "long int" works and is 64 bits */
/* #undef HAVE_LONG_INT_64 *//* Set to 1 if type "long long int" works and is 64 bits */
#define HAVE_LONG_LONG_INT_64/* Set to 1 if type "long long int" constants should be suffixed by LL */
#define HAVE_LL_CONSTANTS 1/* Define this as the appropriate snprintf format for 64-bit ints, if any
*/ #define INT64_FORMAT "%lld"For Aurora, those lines, along with some others, are:
/* Set to 1 if type "long int" works and is 64 bits */
/* #undef HAVE_LONG_INT_64 *//* Set to 1 if type "long long int" works and is 64 bits */
#define HAVE_LONG_LONG_INT_64/* Set to 1 if type "long long int" constants should be suffixed by LL */
#define HAVE_LL_CONSTANTS 1/* Define this as the appropriate snprintf format for 64-bit ints, if any */
#define INT64_FORMAT "%lld"/*
* We need a #define symbol for sizeof(Datum) for use in some #if tests.
*/
#define SIZEOF_DATUM 4/*
* These must be defined as the alignment requirement (NOT the size) of
* each of the basic C data types (except char, which we assume has align 1).
* MAXIMUM_ALIGNOF is the largest alignment requirement for any C data type.
* ALIGNOF_LONG_LONG_INT need only be defined if HAVE_LONG_LONG_INT_64 is.
*/
#define ALIGNOF_SHORT 2
#define ALIGNOF_INT 4
#define ALIGNOF_LONG 4
#define ALIGNOF_LONG_LONG_INT 8
#define ALIGNOF_DOUBLE 8
#define MAXIMUM_ALIGNOF 8This was built with the RPM spec file using the 'sparc32' utility that builds
the sun4 32bit userland executables.
Apparently there is something wrong with the PGAC configure macro.
Though I'm not clear as to why it fails when there is not native 64bit
type in the compiler. At least I would think it would fail the create
table if it isn't going to support the type.
checking whether long int is 64 bits... no
checking whether long long int is 64 bits... no
checking for strtoll... yes
checking for strtoull... yes
checking for atexit... yes
checking size of unsigned long... 4
checking alignment of short... 2
checking alignment of int... 4
checking alignment of long... 4
checking alignment of double... 8
checking for int8... no
checking for uint8... no
checking for int64... no
checking for uint64... no
Brian Macy
./configure --with-openssl
This fails to find a 64bit native type.
Brian Macy
Lamar Owen wrote:
Show quoted text
On Thursday 17 October 2002 09:28 pm, Tom Lane wrote:
Brian Macy <bmacy@macykids.net> writes:
Only excepts 32bit values and not 64bit. Endian issue?
This is on sparc linux.Specifically Debian. Aurora SPARC Linux does not suffer from this problem.
On Aurora, the userland is 32 bit -- is it possible Debian has a 64 bit
userland? As I detailed in my previous email on this subject, I cannot
reproduce the problem on Aurora SPARC Linux build 0.42, which is based on Red
Hat 7.3.Hmm, did configure find any working 64bit int type? Let's see this part
of your src/include/pg_config.h file:/* Set to 1 if type "long int" works and is 64 bits */
/* #undef HAVE_LONG_INT_64 *//* Set to 1 if type "long long int" works and is 64 bits */
#define HAVE_LONG_LONG_INT_64/* Set to 1 if type "long long int" constants should be suffixed by LL */
#define HAVE_LL_CONSTANTS 1/* Define this as the appropriate snprintf format for 64-bit ints, if any
*/ #define INT64_FORMAT "%lld"For Aurora, those lines, along with some others, are:
/* Set to 1 if type "long int" works and is 64 bits */
/* #undef HAVE_LONG_INT_64 *//* Set to 1 if type "long long int" works and is 64 bits */
#define HAVE_LONG_LONG_INT_64/* Set to 1 if type "long long int" constants should be suffixed by LL */
#define HAVE_LL_CONSTANTS 1/* Define this as the appropriate snprintf format for 64-bit ints, if any */
#define INT64_FORMAT "%lld"/*
* We need a #define symbol for sizeof(Datum) for use in some #if tests.
*/
#define SIZEOF_DATUM 4/*
* These must be defined as the alignment requirement (NOT the size) of
* each of the basic C data types (except char, which we assume has align 1).
* MAXIMUM_ALIGNOF is the largest alignment requirement for any C data type.
* ALIGNOF_LONG_LONG_INT need only be defined if HAVE_LONG_LONG_INT_64 is.
*/
#define ALIGNOF_SHORT 2
#define ALIGNOF_INT 4
#define ALIGNOF_LONG 4
#define ALIGNOF_LONG_LONG_INT 8
#define ALIGNOF_DOUBLE 8
#define MAXIMUM_ALIGNOF 8This was built with the RPM spec file using the 'sparc32' utility that builds
the sun4 32bit userland executables.
On Friday 18 October 2002 12:27 am, Brian Macy wrote:
Apparently there is something wrong with the PGAC configure macro.
Though I'm not clear as to why it fails when there is not native 64bit
type in the compiler. At least I would think it would fail the create
table if it isn't going to support the type.
Interesting. Something in the Debian compiler is different; it is 2.95
instead of the Red Hat 2.96 I have on Aurora.
checking whether long int is 64 bits... no
checking whether long long int is 64 bits... no
checking for strtoll... yes
checking for strtoull... yes
checking for atexit... yes
checking size of unsigned long... 4
checking alignment of short... 2
checking alignment of int... 4
checking alignment of long... 4
checking alignment of double... 8
checking for int8... no
checking for uint8... no
checking for int64... no
checking for uint64... no
Mine on Aurora is this:
checking whether long int is 64 bits... no
checking whether long long int is 64 bits... yes
checking whether snprintf handles 'long long int' as %lld... yes
checking for strtoll... yes
checking for strtoull... yes
checking for atexit... yes
checking size of unsigned long... 4
checking alignment of short... 2
checking alignment of int... 4
checking alignment of long... 4
checking alignment of long long int... 8
checking alignment of double... 8
checking for int8... no
checking for uint8... no
checking for int64... no
checking for uint64... no
The only difference is the long long int is 64 bits here.
So, Tom, what's up with that?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Brian Macy <bmacy@macykids.net> writes:
checking whether long int is 64 bits... no
checking whether long long int is 64 bits... no
Well, that seems to be the problem. Perhaps the relevant section of
config.log would offer some hints?
regards, tom lane
The config.log wasn't very useful but I hacked configure to not send
compile/run errors to /dev/null and got this:
checking whether long long int is 64 bits... ./conftest: relocation
error: ./conftest: undefined symbol: __muldi3
Apparrently something is whacked when running from configure. I can take
the exact code (minus the confdefs.h) and run it from the command-line
and it compiles, links, and executes fine (returns 0).
[] config.log:
configure:7610: checking whether long long int is 64 bits
configure:7648: gcc -o conftest -O2 conftest.c -lssl -lcrypto -lz
-lcrypt -lresolv -lnsl -ldl -lm 1>&5
configure: failed program was:
#line 7619 "configure"
#include "confdefs.h"
typedef long long int int64;
/*
* These are globals to discourage the compiler from folding all the
* arithmetic tests down to compile-time constants.
*/
int64 a = 20000001;
int64 b = 40000005;
int does_int64_work()
{
int64 c,d;
if (sizeof(int64) != 8)
return 0; /* definitely not the right size */
/* Do perfunctory checks to see if 64-bit arithmetic seems to work */
c = a * b;
d = (c + b) / b;
if (d != a+1)
return 0;
return 1;
}
main() {
exit(! does_int64_work());
}
Tom Lane wrote:
Show quoted text
Brian Macy <bmacy@macykids.net> writes:
checking whether long int is 64 bits... no
checking whether long long int is 64 bits... noWell, that seems to be the problem. Perhaps the relevant section of
config.log would offer some hints?regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
Brian Macy <bmacy@macykids.net> writes:
The config.log wasn't very useful but I hacked configure to not send
compile/run errors to /dev/null and got this:
checking whether long long int is 64 bits... ./conftest: relocation
error: ./conftest: undefined symbol: __muldi3
Apparrently something is whacked when running from configure. I can take
the exact code (minus the confdefs.h) and run it from the command-line
and it compiles, links, and executes fine (returns 0).
Bizarre. Did your manual test include the same library options (-lssl
etcetera) that configure was using?
If memory serves, __muldi3 is a subroutine in libgcc, which ought to be
automatically included in any link performed by gcc. It seems on this
evidence that one or more of the libraries being linked is somehow
interfering with libgcc ... but I'm darned if I see the problem ...
regards, tom lane
Yeah, weird... Steve Dunham narrowed the problem down to libssl and
posted it to the debian-sparc list, Ben Collins, and appended the info
to the postgres bug report. Hopefully it will be resolved for Debian
unstable shortly.
Brian Macy
Tom Lane wrote:
Show quoted text
Brian Macy <bmacy@macykids.net> writes:
The config.log wasn't very useful but I hacked configure to not send
compile/run errors to /dev/null and got this:checking whether long long int is 64 bits... ./conftest: relocation
error: ./conftest: undefined symbol: __muldi3Apparrently something is whacked when running from configure. I can take
the exact code (minus the confdefs.h) and run it from the command-line
and it compiles, links, and executes fine (returns 0).Bizarre. Did your manual test include the same library options (-lssl
etcetera) that configure was using?If memory serves, __muldi3 is a subroutine in libgcc, which ought to be
automatically included in any link performed by gcc. It seems on this
evidence that one or more of the libraries being linked is somehow
interfering with libgcc ... but I'm darned if I see the problem ...regards, tom lane