To: selkovjr@mcs.anl.gov
cc: Lonnie Cumberland <lonnie_cumberland@yahoo.com>,
	pgsql-interfaces@postgresql.org
Subject: Re: backend debug information 
In-reply-to: <200104162044.PAA00749@selkovjr.xnet.com> 
References: <20010416192226.52764.qmail@web12503.mail.yahoo.com>
	<200104162044.PAA00749@selkovjr.xnet.com>
Comments: In-reply-to selkovjr@mcs.anl.gov
	message dated "Mon, 16 Apr 2001 15:44:32 -0500"
Date: Mon, 16 Apr 2001 17:24:30 -0400
Message-ID: <19258.987456270@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

selkovjr@mcs.anl.gov writes:
> As far as debugging, short of being able to run a postgres under gdb
> while connecting clients to it (I wish I knew whether that was at all
> possible),

It's easy to attach gdb to a running backend process; I do that all the
time.  Usual procedure is:

	1. Fire up psql in another window
	2. Determine PID of backend attached to your psql
	3. gdb /path/to/postgres/executable
	4. "attach PID"
	5. Set breakpoint at desired location(s), continue
	6. Execute problem query in psql

On some platforms you don't have to mention the executable file, as
gdb can figure it out by looking at the process you attach to.  On
others you need to give it.

Setting breakpoints in dynamically loaded shared libraries (ie, user
datatype code) may be easy, painful, or impossible depending on your
platform.  However, you usually can catch a SEGV in such code in any
case; just let the failure happen while gdb is attached.

Don't forget to build your datatype code with -g, and the backend too,
or you'll not be able to learn much.

			regards, tom lane