From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | M2Y <mailtoyahoo(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Debugging methods |
Date: | 2008-09-04 16:03:46 |
Message-ID: | 23959.1220544226@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
M2Y <mailtoyahoo(at)gmail(dot)com> writes:
> I am a beginner to Postgres and I am going through code. I would like
> to know the debugging methods used in development.
> Some of my requirements are; for a given query, how parse structures
> are created in pg_parse_query, how they are analyzed and rewritten in
> pg_analyze_and_rewrite and how the final plan is created in
> pg_plan_queries.
What I tend to do when trying to debug those areas is to set breakpoints
at interesting places with gdb, and then use commands like
"call pprint(node_pointer)" to dump the contents of specific parse or
plan trees to the postmaster log. The reason that outfuncs.c supports
so many node types (many that can't ever appear in stored rules) is
exactly to make it useful for examining internal data structures this
way.
Another possibility is to turn on debug_print_plan and so on, but those
settings only show you the finished results of parsing or planning,
which isn't real helpful for understanding how the code gets from point
A to point B.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-09-04 16:18:16 | Re: StartupCLOG |
Previous Message | Simon Riggs | 2008-09-04 15:58:55 | Re: StartupCLOG |