Re: Debugging postgresql source on gdb

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

In response to

Responses

Browse pgsql-general by date

  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