
How do you people look at various trees and lists when debugging them ?

Do you 

1. use functions from nodes/print.c to print out tree snapshots

2. run the backend under visual debugger (like DDD) and look at things
there

3. memorize everything in binary and work on raw memory image from
/proc/core ;)

4. use some other method


I am currently working on understanding enough of the parse/plan/execute 
process to make up a good plan for implementing WITH RECURSIVE ...
SELECT ...
and perhaps GROUP BY ROLLUP(a,b,c) from SQL99 spec and I'm not
proceeding 
as fast as I'd like ;-p

Also could anyone recommend any tools for debugging gram.y or is this
also 
done mostly by hand even for large grammars ?

------------------
Hannu

Wed, 02 Jan 2002 15:25:10 +0200
Hannu Krosing <hannu@tm.ee>
how to watch parse/plan trees
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 
> process 

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
   case.)
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.

-- 
Holger Krug
hkrug@rationalizer.com

Wed, 2 Jan 2002 15:34:11 +0100
Holger Krug <hkrug@rationalizer.com>
Re: how to watch parse/plan trees
Hannu Krosing <hannu@tm.ee> writes:
> How do you people look at various trees and lists when debugging them ?

I tend to start psql with PGOPTIONS="-d2" and then look at the
prettyprinted trees in the postmaster log.

If you have a bug that prevents you from getting as far as the parsetree
dump, however, gdb is probably the only way.

> Also could anyone recommend any tools for debugging gram.y or is this
> also done mostly by hand even for large grammars ?

Once you've got rid of any shift/reduce or reduce/reduce conflicts
(bison -v output is helpful for that), I find that the grammar itself
seldom has any surprising behaviors that you need to use a debugger
to follow.

			regards, tom lane

Wed, 02 Jan 2002 11:41:08 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: how to watch parse/plan trees 