Thread: 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: > 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.
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: > 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.
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
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: > 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
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:
> 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
>
> ---------------------------(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
>