Re: postgres under gdb

Chris <chris@bitmead.com> writes:

How do you run postgres under gdb?

If you are running a standalone backend, you just fire it up.
For normal use under a postmaster, the easiest thing I've found is to
start psql (or your favorite client) in one window, start gdb on the
postgres executable in another, and then "attach" to the already-started
backend process. (Use "ps" to discover the backend's PID.) You must
run gdb as postgres, of course, but the client process can belong to
anyone.

It gets a little tricky if you are trying to debug part of the
backend startup sequence. We have a kluge for that: start psql
with PGOPTIONS="-W n". That causes the backend to sleep() for n
seconds fairly early in its startup, giving you time to attach to it
before anything really interesting happens.

In theory you can debug one backend in a live production system
this way, but I wouldn't recommend doing that except in dire need.
If you use gdb to stop the backend while it is holding a lock, you'll
block other backends too --- and holding a spinlock is even worse,
because those other backends will time out after a minute or so.
Better to use a playpen installation.

(Hey Bruce, shouldn't this info be in FAQ_DEV?)

I have added this to the main FAQ under debugging:

Another method is to start psql in one window, then find the PID of the
postgres process used by the psql. Use a debugger to attach to the
postgres PID. You can set breakpoints in the debugger and issue queries
from psql. If you are debugging postgres startup, you can set
PGOPTIONS="-W n", then start psql. This will cause startup to delay for
n seconds so you can attach with the debugger and trace through the
startup sequence.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026