Thread: Problem restoring db-dump on Postgres 8.0.4 Power5

"Peter Alberer" <peter.alberer@wu-wien.ac.at> writes:
> The command

> CREATE SEQUENCE assignment_task_elements_seq2
>     INCREMENT BY 1
>     MAXVALUE 9223372036854775807
>     NO MINVALUE
>     CACHE 1;

> Causes the following error: MINVALUE (1) must be less than MAXVALUE (-1)

Not for me.  What *exactly* is the platform you are working on; what
compiler did you build Postgres with; and with what options?  It looks
like something is narrowing the 64-bit maxvalue to 32 bits, but it's far
from clear why.

Have you run the PG regression tests on this build, and do they pass
(particularly the int8 test)?

            regards, tom lane

The platform is a redhat advanced server 4 update 2 for power5 64bit. the
compiler is gcc:

Reading specs from /usr/lib/gcc/ppc64-redhat-linux/3.4.4/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=ppc64-redhat-linux --build=ppc64-redhat-linux
--target=ppc64-redhat-linux --with-cpu=default32
Thread model: posix
gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)

As you can see there is this funny "--with-cpu=default32" switch. So I
usually do a "gcc -m64" to compile things for 64bit executables. Apart from
the failure I got today I did not see any problems with the pg804 build,
done with -m64.

The regression test fails 3 times, I am attaching the diffs. I think the
numerology and union fails are related to the int4 failure. The int8 test
works...

We had a conversation about my compiler installation a few months ago. The
problems I had at that time where related to the parameter ACCEPT_TYPE_ARG3
which on my system gets defined as size_t, but should be socklen_t ...

Regards, peter

Hmmm, i suspect the problem comes from the fact that i did not globally
change gcc to use -m64 nor did I set the enviroment flags (CFLAGS), but
changed the command in the makefile. The configure script did its tests with
the default -m32 and did not define HAVE_LONG_INT_64. Maybe even
INT64_IS_BUSTED is defined for my system...

I tried to run configure with the CFLAGS set to -m64 and it successfully
sets HAVE_LONG_INT_64 in src/include/pg_config.h. So that seems to be my
problem! Btw, after setting the CFLAGS prior to running configure even
ACCEPT_TYPE_ARG3 is defined to be socklen_t.

What do I have to do now? Can I simply continue to run my database instance
(from the existing binary data dictionary) after a recompile/reinstall of
the postgres binaries with a configure script aware of -m64? Or do I have to
fear that the instance is corrupted somehow? Should I do a dump/restore?

Regards, peter

Peter Alberer" <peter.alberer@wu-wien.ac.at> writes:
> Hmmm, i suspect the problem comes from the fact that i did not globally
> change gcc to use -m64 nor did I set the enviroment flags (CFLAGS), but
> changed the command in the makefile. The configure script did its tests with
> the default -m32 and did not define HAVE_LONG_INT_64. Maybe even
> INT64_IS_BUSTED is defined for my system...

Ah-hah, that would definitely explain some funny behavior in this area.

> I tried to run configure with the CFLAGS set to -m64 and it successfully
> sets HAVE_LONG_INT_64 in src/include/pg_config.h. So that seems to be my
> problem! Btw, after setting the CFLAGS prior to running configure even
> ACCEPT_TYPE_ARG3 is defined to be socklen_t.

Did anything else change in pg_config.h --- in particular, the
ALIGNOF_xxx and MAXIMUM_ALIGNOF values?

> What do I have to do now? Can I simply continue to run my database instance
> (from the existing binary data dictionary) after a recompile/reinstall of
> the postgres binaries with a configure script aware of -m64? Or do I have to
> fear that the instance is corrupted somehow? Should I do a dump/restore?

If any of the ALIGNOF symbols changed, then you'll need to do a
dump/restore.  If not, I think you will be OK ... but it would be smart
to make a dump before switching, just in case.

            regards, tom lane