Hi,

i am having a problem with a test installation of postgres 8.0.3 on a 64-bit
power5 system. Let me say first that the system seems to work correctly when
compiled in 32-bit mode (which seems to be standard compile mode with gcc on
this installation).

I compiled postgres in 64-bit mode by adding the following switches in the
make file:
To the gcc lines: -m64 -mcpu=power5 -mtune=power5
To ld lines: -m elf64ppc

Compiling in 64-bit mode also seems to work, but there is an error when
trying to access the postmaster process:

Server starts:
[postgres@testxx pg803]$ bin/postmaster -D /opt/test/data
LOG: could not send test message on socket for statistics collector:
Destination address required
LOG: disabling statistics collector for lack of working socket
LOG: database system was shut down at 2005-09-15 13:42:43 CEST
LOG: checkpoint record is at 0/AB8AD8
LOG: redo record is at 0/AB8AD8; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 544; next OID: 17230
LOG: database system is ready

Client connects:
[root@testxx pg803]# bin/psql -U nsadmin -l
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

Server says:
LOG: setsockopt(TCP_NODELAY) failed: Operation not supported

Did anyone have a similar problem and can provide some help?

TIA, peter

Ps:

The system is using the following gcc config:
Reading specs from /usr/lib/gcc/ppc64-redhat-linux/3.4.3/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.3 20050227 (Red Hat 3.4.3-22.1)


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

"Peter Alberer" <peter.alberer@wu-wien.ac.at> writes:
> Server says:
> LOG: setsockopt(TCP_NODELAY) failed: Operation not supported

It's pretty unclear why that would fail if it works in 32-bit mode.
Kernel bug maybe? What is the platform exactly?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

The system is a p5-510 running redhat advanced server 4.0 update 1. the
kernel version is 2.6.9-11.EL. what other details about the machine could be
helpful?

regards, peter

-----Ursprüngliche Nachricht-----
Von: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Gesendet: Donnerstag, 15. September 2005 16:22
An: Peter Alberer
Cc: pgsql-general@postgresql.org
Betreff: Re: [GENERAL] Problem with 64-bit Postgres

"Peter Alberer" <peter.alberer@wu-wien.ac.at> writes:
> Server says:
> LOG: setsockopt(TCP_NODELAY) failed: Operation not supported

It's pretty unclear why that would fail if it works in 32-bit mode.
Kernel bug maybe? What is the platform exactly?

regards, tom lane


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

"Peter Alberer" <peter.alberer@wu-wien.ac.at> writes:
> The system is a p5-510 running redhat advanced server 4.0 update 1. the
> kernel version is 2.6.9-11.EL. what other details about the machine could be
> helpful?

Well, it works perfectly fine for me on a ppc64 RHEL machine at Red Hat...

I'm a bit suspicious of your method of getting a 64-bit build by
manually altering the compile/link flags. I believe the recommended
way of switching 32/64 environment is via setarch. I did

ppc64 sh
... configure and build within sub-shell ...

and got a working 64-bit executable without doing any special pushups.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Hmm, i just tried to do the same thing (ppc64 sh, ...) but it seems to me
that the result is a 32bit executable:

[root@testxx pg803]# ldd bin/psql
libpq.so.4 => /opt/learn-bench/pg803/lib/libpq.so.4 (0x0ff95000)
libz.so.1 => /usr/lib/libz.so.1 (0x0fbf0000)
libreadline.so.4 => /usr/lib/libreadline.so.4 (0x000e0000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0x0fc30000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00040000)
libresolv.so.2 => /lib/libresolv.so.2 (0x0fa00000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00080000)
libdl.so.2 => /lib/libdl.so.2 (0x0fe60000)
libm.so.6 => /lib/tls/libm.so.6 (0x0fdd0000)
libc.so.6 => /lib/tls/libc.so.6 (0xf7e97000)
/lib/ld.so.1 (0x0ffd0000)

[root@testxx pg803]# readelf -h bin/psql
ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: PowerPC


When i compiled with the -m64 switch the result was an ELF64 file, and all
of the library references were going to /lib64/ ...

[root@testxx pg803]# ldd bin/psql
libpq.so.4 => /opt/learn-bench/pg803/lib/libpq.so.4
(0x0000008000001000)
libz.so.1 => /usr/lib64/libz.so.1 (0x000000802bcb0000)
libreadline.so.4 => /usr/lib64/libreadline.so.4 (0x000000802bdb0000)
libtermcap.so.2 => /lib64/libtermcap.so.2 (0x000000802bc80000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000008000052000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x000000802c200000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x000000802de20000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000802bc60000)
libm.so.6 => /lib64/tls/libm.so.6 (0x000000802bbd0000)
libc.so.6 => /lib64/tls/libc.so.6 (0x000000802ba40000)
/lib64/ld64.so.1 (0x000000802ba00000)

[root@testxx pg803]# readelf -h bin/psql
ELF Header:
Magic: 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: PowerPC64

What elf-class did your compilation produce? Is my assumption, that it
should be elf64 for a 64-bit executable correct?

Regards, peter



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"Peter Alberer" <peter.alberer@wu-wien.ac.at> writes:
> Hmm, i just tried to do the same thing (ppc64 sh, ...) but it seems to me
> that the result is a 32bit executable:

Hmm ... I got an elf64 executable. I'm not entirely sure what drives
gcc's default choices about such things [ digs around... ] The compiler
I was using says this for "gcc -v"

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-languages=c,c++,objc,java,f77 --enable-java-awt=gtk --host=ppc64-redhat-linux
Thread model: posix
gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)

I see "--with-cpu=default32" in your config, which is probably the
significant difference, but I don't know what you should do to change
that.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Sep 15, 2005, at 9:56 AM, Peter Alberer wrote:

> I compiled postgres in 64-bit mode by adding the following switches
> in the
> make file:
> To the gcc lines: -m64 -mcpu=power5 -mtune=power5
> To ld lines: -m elf64ppc
>

FWIW Postgres works splendidly in 64-bit mode on FreeBSD on Opteron
systems.

Perhaps it is a bug in the power5 gcc compiler? Turn off machine
specific tuning and see what happens.

Vivek Khera, Ph.D.
+1-301-869-4449 x806



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend