Обсуждение: hung postmaster?
I'm seeing some unpleasant database cluster seizures. After running fine for hours, days, even weeks, all of a sudden new connections via psql, DBI, libpq, all completely hang with no log message or error, while existing connections can continue to execute queries, log messages, etc. Postmaster is totally unresponsive to SIGTERM, SIGINT, and SIGQUIT (sigkill is the only thing that shuts it down). Memory, CPU, and available connections are plentiful. Top, ps, glance, ls, netstat all are very responsive. I/O load has been pretty high, averaging 700-1100 physical IOs/second. The first time this occurred, last Friday, it was a mix of our 7.3.4 and 7.4.6 clusters. Yesterday, it was all of the 7.4.6 64-bit clusters, none of the 32-bit 7.3.4 clusters. Today it was two of the 7.4.6 clusters and no others. I'm trying to get gdb installed so I can attach to postmaster and get a backtrace. Other troubleshooting ideas appreciated. Details below... CONFIG: ======== Hardware: One HP 64-bit Itanium rx4640, 16gb RAM, 4 cpus, SAN (Cisco switches, HP EVA-5000 disk array and FC HBA's). OS: HP-UX B.11.23 Pgsql: 9 clusters installed and concurrently running. 4/9 are 32-bit PostgreSQL 7.3.4 on ia64-hp-hpux11.22, compiled by cc -Ae. The other 5 clusters are 64-bit PostgreSQL 7.4.6 on ia64-hp-hpux11.23, compiled by gcc 3.3.2. (We have 2 other identical boxes running without incident with similar cluster mixes of 7.3.4, 7.3.7, 7.4.6.)
"Ed L." <pgsql@bluepolka.net> writes:
> Postmaster is totally
> unresponsive to SIGTERM, SIGINT, and SIGQUIT (sigkill is the
> only thing that shuts it down).
gdb backtrace definitely sounds like a good idea. Also it might be
interesting to see the results of strace of the postmaster while hitting
it with signals. Find out if it's doing anything at all in response ...
regards, tom lane
On Wednesday February 16 2005 8:54, Tom Lane wrote: > "Ed L." <pgsql@bluepolka.net> writes: > > Postmaster is totally > > unresponsive to SIGTERM, SIGINT, and SIGQUIT (sigkill is > > the only thing that shuts it down). > > gdb backtrace definitely sounds like a good idea. Also it > might be interesting to see the results of strace of the > postmaster while hitting it with signals. Find out if it's > doing anything at all in response ... Workin' on gdb/strace build, but having trouble with both. Gdb just doesn't build from source, not sure why yet, and no depots found at porting center. It doesn't appear that strace is supported for 11.23 itanium based on strace README/PORTING files and 'man 2 ptrace'. HPUX users, is that your experience? Question: Am I doing all I can to avoid corruption with the following procedure to shutdown a 7.4.6 cluster with a hung postmaster? Suggestions? 1. SIGTERM non-postmaster processes 2. SIGINT non-postmasters 3. SIGQUIT non-postmaster 4. SIGTERM postmaster 5. SIGINT postmaster 6. SIGQUIT postmaster 7. SIGKILL postmaster TIA. Ed
On Wed, Feb 16, 2005 at 11:41:35AM -0700, Ed L. wrote: > Question: Am I doing all I can to avoid corruption with the > following procedure to shutdown a 7.4.6 cluster with a hung > postmaster? Suggestions? What is the state of the processes in ps? D, S, R, ?? That should at least give a hint as to what it *is* doing... > 1. SIGTERM non-postmaster processes > 2. SIGINT non-postmasters > 3. SIGQUIT non-postmaster > 4. SIGTERM postmaster > 5. SIGINT postmaster > 6. SIGQUIT postmaster > 7. SIGKILL postmaster The options you can give to pg_ctl should cover all the possibilities... There's also a page in the docs as to what each process does with each signal... Hope this helps, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Вложения
On Wednesday February 16 2005 3:38, Martijn van Oosterhout wrote: > On Wed, Feb 16, 2005 at 11:41:35AM -0700, Ed L. wrote: > > Question: Am I doing all I can to avoid corruption with the > > following procedure to shutdown a 7.4.6 cluster with a hung > > postmaster? Suggestions? > > What is the state of the processes in ps? D, S, R, ?? That > should at least give a hint as to what it *is* doing... The postmasters were sleeping. I was able to trace a local hung psql client through lsof-->netstat to see the connection was in tcp "ESTABLISHED" state. Anyway, before we installed gdb (wdb) from hp dvd to get a backtrace, I'd already guessed it could be a problem with the build since the 7.4.6 build that was hanging was built with gcc 3.2.2, while the 7.4.6 builds on two other identical boxes were built with gcc 3.4.2. So we shutdown all the 7.4.6 clusters, rebuilt using gcc 3.4.2, identical build steps AFAICS, and this nasty problem has apparently gone away (knock on wood). I have saved a copy of the problematic gcc-3.2.2-built 7.4.6 installation executables, libraries, etc. in case anyone is interested. Time permitting, I may fire them up with a new cluster and see if I can recreate the problem to get a backtrace. Thanks. Ed
On Friday February 18 2005 11:01, Ed L. wrote: > it could be a problem with the > build since the 7.4.6 build that was hanging was built with > gcc 3.2.2, while the 7.4.6 builds on two other identical boxes > were built with gcc 3.4.2. So we shutdown all the 7.4.6 > clusters, rebuilt using gcc 3.4.2, identical build steps > AFAICS, and this nasty problem has apparently gone away (knock > on wood). Correction: problem was with gcc 3.3.2 build, not gcc 3.2.2.
OK, it appears I can reproduce this bug in fairly short
order. Below are gdb backtraces along with current
snapshots from ps, netstat, and a snippet of the server
log. This is no longer an urgent issue for me with the
gcc 3.4.2 workaround available, but I do have a stalled
test cluster postmaster right now, so I can leave it up
for a while if anyone cares for more information.
The identical source built in the identical fashion and
running on the same hardware, but using gcc 3.4.2
instead of gcc 3.3.2, continues to work fine and does
not exhibit this problem so far. Again, this is 64-bit
PostgreSQL 7.4.6 on HP-UX B.11.23 on ia64 box.
Details of current hang...
PIDS 29080 and 26752 in the listing below are hung,
apparently because the postmaster is hung (PID 28775).
PID 26752 is a remote psql client that wanted to just
connect, select version(), and disconnect. I had
that going in a loop, and this PID was the first to
hang; PID 29080 is a local psql client.
$ps -u pg -lf
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME COMD
1401 S pg 28777 28775 0 154 20 e000000170fcf4c0 1162 e000000164f7e0c0 13:41:07 pts/3 0:00 postgres: stats
bufferprocess
1401 S pg 28775 1 0 154 20 e00000016a5b5940 1118 e0000001744340e8 13:41:07 pts/3 0:00
/opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/bin/postm
1401 S pg 26752 28629 0 154 20 e000000191e03280 101 e000000164f7e100 18:09:01 pts/3 0:00 psql -l
401 R pg 7130 26918 1 178 20 e00000016adac4c0 68 - 18:29:42 pts/11 0:00 ps -u pg -lf
1401 S pg 28778 28777 0 154 20 e00000016c591700 1130 e000000164f7e100 13:41:07 pts/3 0:00 postgres: stats
collectorprocess
401 S pg 28629 4112 0 158 20 e00000016aecc940 333 e000000170f9c000 13:40:53 pts/3 0:00 -sh
401 S pg 26918 26887 0 158 20 e00000016c2a0280 351 e000000171506000 18:09:24 pts/11 0:00 -sh
1421 T pg 29080 26918 0 154 20 e00000016a90f940 101 - 18:13:25 pts/11 0:00 psql -c select
version()
$which postmaster
/opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/bin/postmaster
$gdb `which postmaster`
HP gdb 5.0 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.0 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
(gdb) attach 28775
Attaching to program: /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/bin/postmaster, process 28775
Reading symbols from /usr/lib/hpux64/libxnet.so.1...done.
Reading symbols from /usr/lib/hpux64/libc.so.1...done.
Reading symbols from /usr/lib/hpux64/libgen.so.1...done.
Reading symbols from /usr/lib/hpux64/libdl.so.1...done.
Reading symbols from /usr/lib/hpux64/libnsl.so.1...done.
Reading symbols from /usr/lib/hpux64/libm.so.1...done.
Reading symbols from /usr/lib/hpux64/libxti.so.1...done.
Reading symbols from /usr/lib/hpux64/libnss_files.so.1...done.
0xc000000000304230:0 in _accept_sys+0x30 () from /usr/lib/hpux64/libc.so.1
(gdb) bt
#0 0xc000000000304230:0 in _accept_sys+0x30 () from /usr/lib/hpux64/libc.so.1
#1 0xc0000000003100b0:0 in accept+0x150 () from /usr/lib/hpux64/libc.so.1
#2 0xc000000001aac450:0 in accept+0x70 () from /usr/lib/hpux64/libxnet.so.1
#3 0x4000000000275df0:0 in StreamConnection+0x40 ()
#4 0x40000000002e7da0:0 in ConnCreate+0x80 ()
#5 0x40000000002e6530:0 in ServerLoop+0x3b0 ()
#6 0x40000000002e5740:0 in PostmasterMain+0x1300 ()
#7 0x4000000000279800:0 in main+0x520 ()
(gdb) p debug_query_string
$1 = 0
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n) Detaching from program:
/opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/bin/postmaster,process 28775
$which postmaster
/opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/bin/psql
$gdb `which psql`
HP gdb 5.0 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.0 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
(gdb) attach 26752
Attaching to program: /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/bin/psql, process 26752
Reading symbols from /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/lib/libpq.so.3...done.
Reading symbols from /usr/lib/hpux64/libxnet.so.1...done.
Reading symbols from /usr/lib/hpux64/libc.so.1...done.
Reading symbols from /usr/lib/hpux64/libgen.so.1...done.
Reading symbols from /usr/lib/hpux64/libdl.so.1...done.
Reading symbols from /usr/lib/hpux64/libnsl.so.1...done.
Reading symbols from /usr/lib/hpux64/libm.so.1...done.
Reading symbols from /usr/lib/hpux64/libxti.so.1...done.
0xc000000000301e70:0 in _poll_sys+0x30 () from /usr/lib/hpux64/libc.so.1
(gdb) bt
#0 0xc000000000301e70:0 in _poll_sys+0x30 () from /usr/lib/hpux64/libc.so.1
#1 0xc000000000313110:0 in poll+0x150 () from /usr/lib/hpux64/libc.so.1
#2 0xc00000002d36ee70:0 in pqSocketPoll+0x110 ()
from /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/lib/libpq.so.3
#3 0xc00000002d36ec40:0 in pqSocketCheck+0x80 ()
from /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/lib/libpq.so.3
#4 0xc00000002d36eac0:0 in pqWaitTimed+0x40 ()
from /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/lib/libpq.so.3
#5 0xc00000002d362f60:0 in connectDBComplete+0xe0 ()
from /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/lib/libpq.so.3
#6 0xc00000002d362500:0 in PQsetdbLogin+0x410 ()
from /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/lib/libpq.so.3
#7 0x40000000000218f0:0 in main+0x510 ()
(gdb) p debug_query_string
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n) Detaching from program:
/opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/bin/psql,process 26752
$gdb `which psql`
HP gdb 5.0 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.0 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
(gdb) attach 29080
Attaching to program: /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/bin/psql, process 29080
Reading symbols from /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/lib/libpq.so.3...done.
Reading symbols from /usr/lib/hpux64/libxnet.so.1...done.
Reading symbols from /usr/lib/hpux64/libc.so.1...done.
Reading symbols from /usr/lib/hpux64/libgen.so.1...done.
Reading symbols from /usr/lib/hpux64/libdl.so.1...done.
Reading symbols from /usr/lib/hpux64/libnsl.so.1...done.
Reading symbols from /usr/lib/hpux64/libm.so.1...done.
Reading symbols from /usr/lib/hpux64/libxti.so.1...done.
0xc000000000301e70:0 in _poll_sys+0x30 () from /usr/lib/hpux64/libc.so.1
(gdb) bt
#0 0xc000000000301e70:0 in _poll_sys+0x30 () from /usr/lib/hpux64/libc.so.1
#1 0xc000000000313110:0 in poll+0x150 () from /usr/lib/hpux64/libc.so.1
#2 0xc00000002d36ee70:0 in pqSocketPoll+0x110 ()
from /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/lib/libpq.so.3
#3 0xc00000002d36ec40:0 in pqSocketCheck+0x80 ()
from /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/lib/libpq.so.3
#4 0xc00000002d36eac0:0 in pqWaitTimed+0x40 ()
from /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/lib/libpq.so.3
#5 0xc00000002d362f60:0 in connectDBComplete+0xe0 ()
from /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/lib/libpq.so.3
#6 0xc00000002d362500:0 in PQsetdbLogin+0x410 ()
from /opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/lib/libpq.so.3
#7 0x40000000000218f0:0 in main+0x510 ()
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n) Detaching from program:
/opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/bin/psql,process 29080
$uname -a
HP-UX ... B.11.23 ... ia64 ...
$file `which postmaster`
/opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/bin/postmaster: ELF-64 executable object file - IA64
$file `which psql`
/opt/pgsql/installs/postgresql-7.4.6-gcc3.3.2-B.11.23/bin/psql: ELF-64 executable object file - IA64
$psql -V
psql (PostgreSQL) 7.4.6
$postmaster -V
postmaster (PostgreSQL) 7.4.6
This is the tail end of the server log, showing nothing
was ever logged for the hung connections...
2005-02-18 14:25:45.558 [20313] LOG: connection received: host=10.0.1.80 port=45976
2005-02-18 14:25:45.921 [20313] LOG: connection authorized: user=pg database=pg
2005-02-18 14:25:46.394 [20313] LOG: statement: begin; select getdatabaseencoding(); commit
2005-02-18 14:25:46.395 [20313] LOG: duration: 0.862 ms
2005-02-18 14:25:46.807 [20313] LOG: statement: select version()
2005-02-18 14:25:46.808 [20313] LOG: duration: 0.646 ms
2005-02-18 14:26:47.092 [20818] LOG: connection received: host=10.0.1.80 port=45993
2005-02-18 14:26:47.278 [20818] LOG: connection authorized: user=pg database=pg
2005-02-18 14:26:47.461 [20818] LOG: statement: begin; select getdatabaseencoding(); commit
2005-02-18 14:26:47.462 [20818] LOG: duration: 0.792 ms
2005-02-18 14:26:47.696 [20818] LOG: statement: select version()
2005-02-18 14:26:47.696 [20818] LOG: duration: 0.557 ms
2005-02-18 14:27:47.993 [21220] LOG: connection received: host=10.0.1.80 port=46015
2005-02-18 14:27:48.192 [21220] LOG: connection authorized: user=pg database=pg
2005-02-18 14:27:48.384 [21220] LOG: statement: begin; select getdatabaseencoding(); commit
2005-02-18 14:27:48.385 [21220] LOG: duration: 0.961 ms
2005-02-18 14:27:48.560 [21220] LOG: statement: select version()
2005-02-18 14:27:48.560 [21220] LOG: duration: 0.545 ms
2005-02-18 14:28:48.826 [21702] LOG: connection received: host=10.0.1.80 port=46035
2005-02-18 14:28:49.087 [21702] LOG: connection authorized: user=pg database=pg
2005-02-18 14:28:49.318 [21702] LOG: statement: begin; select getdatabaseencoding(); commit
2005-02-18 14:28:49.319 [21702] LOG: duration: 0.809 ms
2005-02-18 14:28:49.516 [21702] LOG: statement: select version()
2005-02-18 14:28:49.516 [21702] LOG: duration: 0.360 ms
2005-02-18 14:29:49.717 [22047] LOG: connection received: host=10.0.1.80 port=46060
2005-02-18 14:29:49.910 [22047] LOG: connection authorized: user=pg database=pg
2005-02-18 14:29:50.138 [22047] LOG: statement: begin; select getdatabaseencoding(); commit
2005-02-18 14:29:50.139 [22047] LOG: duration: 0.831 ms
2005-02-18 14:29:50.320 [22047] LOG: statement: select version()
2005-02-18 14:29:50.321 [22047] LOG: duration: 0.539 ms
2005-02-18 14:30:50.527 [22359] LOG: connection received: host=10.0.1.80 port=46087
2005-02-18 14:30:50.710 [22359] LOG: connection authorized: user=pg database=pg
2005-02-18 14:30:50.927 [22359] LOG: statement: begin; select getdatabaseencoding(); commit
2005-02-18 14:30:50.928 [22359] LOG: duration: 0.855 ms
2005-02-18 14:30:51.105 [22359] LOG: statement: select version()
2005-02-18 14:30:51.106 [22359] LOG: duration: 0.641 ms
Here's the lsof output for the hung processes... $ lsof | egrep 'PID|28775|29080|26752' COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME psql 26752 pg cwd DIR 64,0x9 2048 12677 /users/pg psql 26752 pg txt REG 64,0x6 242192 50102 /opt (/dev/vg00/lvol6) psql 26752 pg mem REG 64,0x8 532 2544 /var/spool/pwgr/status psql 26752 pg mem REG 64,0x7 312328 5931 /usr/lib/hpux64/libxti.so.1 psql 26752 pg mem REG 64,0x7 1597816 20621 /usr/lib/hpux64/libnsl.so.1 psql 26752 pg mem REG 64,0x7 4279160 5873 /usr/lib/hpux64/libc.so.1 psql 26752 pg mem REG 64,0x7 2068376 5891 /usr/lib/hpux64/libm.so.1 psql 26752 pg mem REG 64,0x7 22848 5878 /usr/lib/hpux64/libdl.so.1 psql 26752 pg mem REG 64,0x7 40016 5883 /usr/lib/hpux64/libgen.so.1 psql 26752 pg mem REG 64,0x7 37928 5929 /usr/lib/hpux64/libxnet.so.1 psql 26752 pg mem REG 64,0x6 218824 50167 /opt (/dev/vg00/lvol6) psql 26752 pg mem REG 64,0x7 705704 5869 /usr/lib/hpux64/dld.so psql 26752 pg mem REG 64,0x7 157912 5925 /usr/lib/hpux64/uld.so psql 26752 pg 0u STR 157,0x3 0t885971 955 ldterm->ptem->pts psql 26752 pg 1u STR 157,0x3 0t885971 955 ldterm->ptem->pts psql 26752 pg 2u STR 157,0x3 0t885971 955 ldterm->ptem->pts psql 26752 pg 3u unix 64,0x8 0t0 8046 /var/spool/sockets/pwgr/client26752 (0x743e5900) psql 26752 pg 4u unix 0x6f1963c0 0t0 ->0x74a76740 postgres 28775 pg cwd DIR 64,0x9 2048 12677 /users/pg postgres 28775 pg txt REG 64,0x6 5071608 50092 /opt (/dev/vg00/lvol6) postgres 28775 pg mem REG 64,0x7 13197 6216 /usr/lib/tztab postgres 28775 pg mem REG 64,0x7 312328 5931 /usr/lib/hpux64/libxti.so.1 postgres 28775 pg mem REG 64,0x7 1597816 20621 /usr/lib/hpux64/libnsl.so.1 postgres 28775 pg mem REG 64,0x7 135488 5892 /usr/lib/hpux64/libnss_files.so.1 postgres 28775 pg mem REG 64,0x7 4279160 5873 /usr/lib/hpux64/libc.so.1 postgres 28775 pg mem REG 64,0x7 2068376 5891 /usr/lib/hpux64/libm.so.1 postgres 28775 pg mem REG 64,0x7 22848 5878 /usr/lib/hpux64/libdl.so.1 postgres 28775 pg mem REG 64,0x7 40016 5883 /usr/lib/hpux64/libgen.so.1 postgres 28775 pg mem REG 64,0x7 37928 5929 /usr/lib/hpux64/libxnet.so.1 postgres 28775 pg mem REG 64,0x7 705704 5869 /usr/lib/hpux64/dld.so postgres 28775 pg mem REG 64,0x7 157912 5925 /usr/lib/hpux64/uld.so postgres 28775 pg 0u CHR 3,0x2 0t0 65 /dev/null postgres 28775 pg 1u REG 64,0x9 28137 49084 /users/pg/server_log postgres 28775 pg 2u REG 64,0x9 28137 49084 /users/pg/server_log postgres 28775 pg 3u sock 0t0 unsupported family: AF_22 postgres 28775 pg 4u inet 0xe0000001742b8900 0t0 TCP *:19001 (LISTEN) postgres 28775 pg 5u unix 64,0x4 0t0 138 /tmp/.s.PGSQL.19001 (0x74974ac0) postgres 28775 pg 6u inet 0xe00000016ef5f580 0t0 UDP localhost:55276->localhost:55276 (Idle) postgres 28775 pg 7r FIFO 0xe00000016a1bc748 0t0 16368987 postgres 28775 pg 8w FIFO 0xe00000016a1bc748 0t0 16368987 psql 29080 pg cwd DIR 64,0x9 2048 12677 /users/pg psql 29080 pg txt REG 64,0x6 242192 50102 /opt (/dev/vg00/lvol6) psql 29080 pg mem REG 64,0x8 532 2544 /var/spool/pwgr/status psql 29080 pg mem REG 64,0x7 312328 5931 /usr/lib/hpux64/libxti.so.1 psql 29080 pg mem REG 64,0x7 1597816 20621 /usr/lib/hpux64/libnsl.so.1 psql 29080 pg mem REG 64,0x7 4279160 5873 /usr/lib/hpux64/libc.so.1 psql 29080 pg mem REG 64,0x7 2068376 5891 /usr/lib/hpux64/libm.so.1 psql 29080 pg mem REG 64,0x7 22848 5878 /usr/lib/hpux64/libdl.so.1 psql 29080 pg mem REG 64,0x7 40016 5883 /usr/lib/hpux64/libgen.so.1 psql 29080 pg mem REG 64,0x7 37928 5929 /usr/lib/hpux64/libxnet.so.1 psql 29080 pg mem REG 64,0x6 218824 50167 /opt (/dev/vg00/lvol6) psql 29080 pg mem REG 64,0x7 705704 5869 /usr/lib/hpux64/dld.so psql 29080 pg mem REG 64,0x7 157912 5925 /usr/lib/hpux64/uld.so psql 29080 pg 0u STR 157,0xb 0t182144 963 ldterm->ptem->pts psql 29080 pg 1u STR 157,0xb 0t182144 963 ldterm->ptem->pts psql 29080 pg 2u STR 157,0xb 0t182144 963 ldterm->ptem->pts psql 29080 pg 3u unix 64,0x8 0t0 8040 /var/spool/sockets/pwgr/client29080 (0x70b593c0) psql 29080 pg 4u unix 0x742b8580 0t0 ->0x717b6040
pgsql@bluepolka.net ("Ed L.") writes:
>
> Workin' on gdb/strace build, but having trouble with both. Gdb
> just doesn't build from source, not sure why yet, and no depots
> found at porting center. It doesn't appear that strace is
> supported for 11.23 itanium based on strace README/PORTING files
> and 'man 2 ptrace'. HPUX users, is that your experience?
>
Ed, HP maintains a port of gdb called wdb (wildebeest). You should be
able to get this from them from http://www.hp.com/go/wdb/ but I'm
getting timeouts trying to connect right now. If this persists, let
me know and I'll try to find a way to get you my most recent download
from Dec 23.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
--
Remove -42 for email