Re: [HACKERS] postgres under gdb

How do you run postgres under gdb?

Chris <chris(at)bitmead(dot)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?)

regards, tom lane

> How do you run postgres under gdb?

gdb postgres
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) b ParseFuncOrColumn
Breakpoint 1 at 0x80e5656: file parse_func.c, line 228.
(gdb) run postgres
Starting program: /opt/postgres/current/bin/postgres postgres
DEBUG: Data Base System is starting up at Thu Jan 27 17:45:46 2000
DEBUG: Data Base System was interrupted being in production at Thu
Jan 27 17:40:53 2000
DEBUG: CheckPoint record at (0, 920)
DEBUG: Redo record at (0, 920); Undo record at (0, 0)
DEBUG: NextTransactionId: 0; NextOid: 0
DEBUG: Invalid NextTransactionId/NextOid
DEBUG: The DataBase system was not properly shut down
Automatic recovery is in progress...
DEBUG: ReadRecord: invalid record len 0 in (0, 968)
DEBUG: Formatting logfile 0 seg 0 block 0 at offset 968
DEBUG: The last logId/logSeg is (0, 0)
DEBUG: Redo is not required
DEBUG: Undo is not required
DEBUG: Data Base System is in production state at Thu Jan 27 17:45:49
2000

POSTGRES backend interactive interface
$Revision: 1.139 $ $Date: 2000/01/09 12:17:33 $

backend> select b from t1 tx (b);

Breakpoint 1, ParseFuncOrColumn (pstate=0x824eb70, funcname=0x824f098
"b", fargs=0x824f0f8, agg_star=0 '\000',
agg_distinct=0 '\000', curr_resno=0x824eb70, precedence=1) at
parse_func.c:228
228 Oid rettype = InvalidOid;
(gdb) l 310
...

You can also give more command line options when you type "run". A
tip: when trying to track down why elog() errors are being thrown, set
a breakpoint on elog itself and then do a "where". Use "frame #" to
bop around the stack. Been doing that a lot lately ;)

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California

>
> How do you run postgres under gdb?
>
> ************
>

See the FAQ. Start postgres as part of gdb and run in there in
standalone mode.

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

> Chris <chris(at)bitmead(dot)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?)

Yes, let me add it.

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

> Chris <chris(at)bitmead(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026