Re: Debugging postgresql source on gdb
От | Sibte Abbas |
---|---|
Тема | Re: Debugging postgresql source on gdb |
Дата | |
Msg-id | bd6a35510707221030p694cd515kfeb529078557ba42@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Debugging postgresql source on gdb (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Debugging postgresql source on gdb
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: