From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Islam Hegazy <islheg(at)gawab(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: debugging C functions |
Date: | 2007-06-02 05:38:52 |
Message-ID: | 1010.1180762732@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Joe Conway <mail(at)joeconway(dot)com> writes:
> [ much good advice snipped, but I have to weigh in on one point ]
> 4. Start another console and determine the PID for the backend
> session (this will wrap poorly -- I'll do my best to make it
> readable)
"select pg_backend_pid()" is another alternative for finding the PID.
Personally I've gotten to the point where manually determining the
backend PID at all is tedious, and so I tend to use this script:
#!/bin/sh
# tee /dev/tty is for user to see the set of procs considered
PROCS=`ps auxww | \
grep postgres: | \
grep -v -e 'grep postgres:' -e 'postgres: stats' -e 'postgres: writer' -e 'postgres: archiver' -e 'postgres: logger' | \
tee /dev/tty | \
awk '{print $2}'`
if [ `echo "$PROCS" | wc -w` -eq 1 ]
then
exec gdb $PGINSTROOT/bin/postgres -silent "$PROCS"
else
exec gdb $PGINSTROOT/bin/postgres -silent
fi
This fails (but gives you a list of processes to consider attaching to)
if there's more than one candidate.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Paolo Bizzarri | 2007-06-02 05:46:03 | Re: Corruption of files in PostgreSQL |
Previous Message | Joshua D. Drake | 2007-06-02 05:12:36 | Re: New Live CD needed |