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-pr-single.pl?number=21750
cpu0: Sun Microsystems UltraSparc-I Processor (200.00 MHz CPU)
