This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: [HACKERS] postgres under gdb From: Bruce Momjian <pgman@candle.pha.pa.us> Date: Thu, 8 Jun 2000 13:31:07 -0400 (EDT) > 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. Subject: Re: [HACKERS] postgres under gdb From: Bruce Momjian <pgman@candle.pha.pa.us> Date: Thu, 8 Jun 2000 13:31:07 -0400 (EDT) > 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. ===