From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Shreya Bhargava <shreya_bhargav(at)yahoo(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Debugging postgresql source on gdb |
Date: | 2007-07-22 05:00:23 |
Message-ID: | 25344.1185080423@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Shreya Bhargava <shreya_bhargav(at)yahoo(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Vincenzo Romano | 2007-07-22 07:24:50 | Re: Difference between PRIMARY KEY index and UNIQUE-NOT NULL index |
Previous Message | Shreya Bhargava | 2007-07-22 04:33:23 | Debugging postgresql source on gdb |