Thanks very much for the suggestions! will try them out ....
regards,
Shreya
Sibte Abbas <[EMAIL PROTECTED]> wrote:
On 7/22/07, Sibte Abbas wrote:
> On 7/22/07, Tom Lane wrote:
> > Shreya Bhargava 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
>
"&&" was a typo, sorry for that. The actual command is:
./configure --enable-debug CFLAGS=-O0
regards,
--
Sibte Abbas
EnterpriseDB http://www.enterprisedb.com
---------------------------------
Choose the right car based on your needs. Check out Yahoo! Autos new Car
Finder tool.
