On Wed, Jan 02, 2002 at 03:25:10PM +0200, Hannu Krosing wrote:
> I am currently working on understanding enough of the parse/plan/execute
I tried the same a few days ago and made very good progress using simply GDB
going through the code step by step as the system executes.
As mentioned in the Developers FAQ using
$ call pprint(nodepointer)
from within GDB and looking at the debug output was very useful.
Only sometimes I called pprint on something which wasn't really a
node-pointer (but a pointer to something else) and in very rare cases
I got nice system crashes because of this;-)
Some hints for the use GDB with PostgreSQL (deviating from what is
recommended in other places):
1) Start postmaster with `LD_DEBUG=files' set in the environment if you need
access to dynamically loaded libraries. (Seems not to be necessary in your
2) Start gdb with all PostgreSQL source directories loaded (I start it
within Emacs, at the same time using the Tags table which can be created
with tools/make_etags, which allows fast code browsing.)
3) Connect with psql.
4) pstree -p | grep postmaster
to get informed about the pid of the backend your psql is connected to.
5) Make the appropriate calls from psql to get all the dynamically loadable
libraries loaded. Follow the PostgreSQL log output to get informed about
the entry addresses of the dynamically loaded libraries. (Not necessary
in your case.)
6) In gdb:
$ file <bindir>/postgres
# now use the entry address which appeared in the logs:
$ add-symbol-file <libdir>/plpgsql.so <entryaddress>
$ add-symbol-file <libdir>/<otherlib>.so <otherentryaddress>
# now use the pid of the backend
$ attach pid
# now work with gdb
This sounds much to do, but works astonishingly well.
In response to
pgsql-hackers by date
|Next:||From: Matthew T. O'Connor||Date: 2002-01-02 14:49:58|
|Subject: Re: problems with new vacuum (??)|
|Previous:||From: Jan Wieck||Date: 2002-01-02 13:40:21|
|Subject: Re: Duplicate-key-detection failure case found in btree|