On a Sun ultra2 sparc64 initdb hangs here:

$ initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user "pgsql".
This user must also own the server process.

The database cluster will be initialized with locale C.

creating directory /usr/local/pgsql/data ... ok
creating directory /usr/local/pgsql/data/global ... ok
creating directory /usr/local/pgsql/data/pg_xlog ... ok
creating directory /usr/local/pgsql/data/pg_xlog/archive_status ... ok
creating directory /usr/local/pgsql/data/pg_clog ... ok
creating directory /usr/local/pgsql/data/pg_subtrans ... ok
creating directory /usr/local/pgsql/data/base ... ok
creating directory /usr/local/pgsql/data/base/1 ... ok
creating directory /usr/local/pgsql/data/pg_tblspc ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 1000
creating configuration files ... ok
creating template1 database in /usr/local/pgsql/data/base/1 ...

After killing initdb with ^C postgres is still running
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
23061 pgsql -8 0 30264K 8984K piperd 0:10 0.00% 0.00% postgres

$ uname -a
FreeBSD ultra2 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8 22:21:34 UTC
2005 root (AT) binkley (DOT) cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sparc64

$ gcc -v
Using built-in specs.
Configured with: FreeBSD/sparc64 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728


PostgreSQL config.status 8.0.3
configured by ./configure, generated by GNU Autoconf 2.53,
with options \"'--with-libraries=/usr/local/lib'
'--with-includes=/usr/local/i
nclude' '--with-docdir=/usr/local/share/doc/postgresql' '--with-openssl'
'--disa
ble-nls' '--enable-thread-safety' '--prefix=/usr/local'
'sparc64-portbld-freebsd
5.4' 'LDFLAGS= -rpath=/usr/lib:/usr/local/lib -L/usr/local/lib' 'CFLAGS=-O
-pipe
' 'CPPFLAGS=-I/usr/local/include' 'host_alias=sparc64-portbld-freebsd5.4'
'buil
d_alias=sparc64-portbld-freebsd5.4' 'target_alias=sparc64-portbld-freebsd5.4'
'C
C=cc'\"

David
--
http://howto.mainstreamlinux.com



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

David Walker <david (AT) cosmicfires (DOT) com> writes:
Where's "here"? Build with --enable-debug, then attach to the stuck
process with gdb and get a stack trace.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

On a Sun ultra2 sparc64 initdb hangs.
cpu0: Sun Microsystems UltraSparc-I Processor (200.00 MHz CPU)

$ initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user "pgsql".
This user must also own the server process.

The database cluster will be initialized with locale C.

creating directory /usr/local/pgsql/data ... ok
creating directory /usr/local/pgsql/data/global ... ok
creating directory /usr/local/pgsql/data/pg_xlog ... ok
creating directory /usr/local/pgsql/data/pg_xlog/archive_status ... ok
creating directory /usr/local/pgsql/data/pg_clog ... ok
creating directory /usr/local/pgsql/data/pg_subtrans ... ok
creating directory /usr/local/pgsql/data/base ... ok
creating directory /usr/local/pgsql/data/base/1 ... ok
creating directory /usr/local/pgsql/data/pg_tblspc ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 1000
creating configuration files ... ok
creating template1 database in /usr/local/pgsql/data/base/1 ...

initdb hangs there, backend status:

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
43332 pgsql -8 0 30264K 8888K piperd 0:11 0.00% 0.00% postgres


(gdb) where
#0 0x0000000040f7f0a8 in read () from /lib/libc.so.5
#1 0x0000000040ffdd54 in __sread () from /lib/libc.so.5
#2 0x0000000040ffddd8 in _sread () from /lib/libc.so.5
#3 0x0000000040fe8954 in __srefill () from /lib/libc.so.5
#4 0x0000000040fe2e40 in fread () from /lib/libc.so.5
#5 0x000000000016a0d8 in Int_yy_get_next_buffer () at lex.Int_yy.c:1217
#6 0x0000000000169c9c in Int_yylex () at lex.Int_yy.c:1052
#7 0x0000000000168674 in Int_yyparse () at y.tab.c:1090
#8 0x000000000016b2b8 in BootstrapMain (argc=4, argv=0x7fdffffeb58)
at bootstrap.c:455
#9 0x00000000001fc774 in main (argc=5, argv=0x7fdffffeb50) at main.c:296


(gdb) disassemble
Dump of assembler code for function read:
0x0000000040f7f0a0 <read+0>: mov 3, %g1 ! 0x3
0x0000000040f7f0a4 <read+4>: ta %xcc, -4031
0x0000000040f7f0a8 <read+8>: bcc,a %xcc, 0x40f7f0bc <read+28>
0x0000000040f7f0ac <read+12>: nop
0x0000000040f7f0b0 <read+16>: mov %o7, %g1
0x0000000040f7f0b4 <read+20>: b 0x4110f600 <__sglue+9496>
0x0000000040f7f0b8 <read+24>: mov %g1, %o7
0x0000000040f7f0bc <read+28>: retl
0x0000000040f7f0c0 <read+32>: nop


Could this the be bug described in this URL?
http://www.netbsd.org/cgi-bin/query-...l?number=21750

cpu0: Sun Microsystems UltraSparc-I Processor (200.00 MHz CPU)



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

On 2005-05-13, Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> wrote:
I've just done some analysis on this on David's machine - the bottom line
is that -enable-thread-safety is broken on this platform, but I've not
yet established for certain whether this is a bug in freebsd or incorrect
compiler options in pg's configure (will be looking into that in due
course)

The reason for the hang is that the sending end of the pipe from initdb
to postgres is not being closed by popen(), so postgres never sees EOF
on it. In this context I am suspicious of the fact that while libpq is
being built with threading, the apps which link against it do not appear
to be.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

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

http://archives.postgresql.org

Andrew - Supernews <andrew+nonews (AT) supernews (DOT) com> writes:
initdb does not use libpq ... it might link to it, because of sloppy
LIBS list management, but it doesn't ever call it. There is, by
definition, no running postmaster available for libpq to contact.

regards, tom lane

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

On 2005-05-21, Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> wrote:
Linking to it is enough to bring in libc_r, and pick up libc_r's versions
of at least some system calls. The ktrace results show this.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

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

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

Andrew - Supernews <andrew+nonews (AT) supernews (DOT) com> writes:
[ shrug... ] If libc_r behaves differently than libc in an app that
doesn't create multiple threads, I think that's an issue to be taking up
with the libc developers not us.

regards, tom lane

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

http://archives.postgresql.org

On 2005-05-21, Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> wrote:
Further investigation (not yet complete) suggests that this is a link order
dependency problem. It kicks in because libpq is being linked explicitly
with -lc_r (which should not be necessary or desirable), causing libc and
libc_r to be linked in the wrong order if the executable is _not_ linked
with -pthread.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)