Search Postgresql Archives

Re: Debugging postgresql source on gdb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux