On 7/22/07, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Shreya Bhargava <shreya_bhargav@xxxxxxxxx> writes:
> 1. gdb postgres
> 2. set args -D test (test is my dbcluster)
> 3. b hashbuild(this is the function i want to break on)
> 4. run
You've set the breakpoint in the postmaster process. It won't propagate
to child backends, at least not without special gdb pushups.
The way that I usually debug things is to start the client psql job,
then determine the PID of the backend serving it, and "attach" to
that process in gdb.
In a development environment where you're likely to have only one or
a few backends running, this shell script might help:
#!/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' -e 'postgres: autovacuum' | \
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 will attach directly to the target backend if there's only one,
else you can examine the ps output to determine which PID to attach to.
regards, tom lane
Also, for gdb to function properly, you should compile the source with
--enable-debug and no compiler optimization i.e:
./configure --enable-debug && CFLAGS=-O0
regards,
--
Sibte Abbas
EnterpriseDB http://www.enterprisedb.com
