Re: backend debug information

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: selkovjr(at)mcs(dot)anl(dot)gov
Cc: Lonnie Cumberland <lonnie_cumberland(at)yahoo(dot)com>, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: backend debug information
Date: 2001-04-16 21:24:30
Message-ID: 19258.987456270@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

selkovjr(at)mcs(dot)anl(dot)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

In response to

Browse pgsql-interfaces by date

  From Date Subject
Next Message selkovjr 2001-04-16 23:07:00 Re: making data types
Previous Message selkovjr 2001-04-16 20:44:32 Re: backend debug information