Re: debugging C functions

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

In response to

Responses

Browse pgsql-general by date

  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