[BUGS] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Pg 7.2.3 int8 value out of range
Brian Macy <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Pg 7.2.3 int8 value out of range
On Thursday 17 October 2002 09:28 pm, Tom Lane wrote: > Brian Macy <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Pg 7.2.3 int8 value out of range
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: On Thursday 17 October 2002 09:28 pm, Tom Lane wrote: Brian Macy <[EMAIL PROTECTED]> 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. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Pg 7.2.3 int8 value out of range
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
