Re: Debugging postgresql source on gdb - Mailing list pgsql-general

From Tom Lane
Subject Re: Debugging postgresql source on gdb
Date
Msg-id 25344.1185080423@sss.pgh.pa.us
Whole thread Raw
In response to Debugging postgresql source on gdb  (Shreya Bhargava <shreya_bhargav@yahoo.com>)
Responses Re: Debugging postgresql source on gdb  ("Sibte Abbas" <sibtay@gmail.com>)
List pgsql-general
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

pgsql-general by date:

Previous
From: Shreya Bhargava
Date:
Subject: Debugging postgresql source on gdb
Next
From: Zlatko Matić
Date:
Subject: Re: encodings