On 7/22/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Shreya Bhargava <shreya_bhargav@yahoo.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
>
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