> > Debugging patches, ah. No gdb yet?
>
> (I see that you fixed it. Great!)
>
> I just cleaned up a little code; enabling some of the debugging
> statements already in this area caused some breakage. Yeah, I'm now
> gdb-enabled with Postgres, and it is very nice, but not if you don't
> know where the code is headed. I could see the parse tree at the back of
> the parser, and I could see the tree at the executor, but had no idea
> where it went in between. Stepping through code didn't seem like a good
> bet since afaik there are hundreds of calls in between...
>
> - Tom
>
I suspected the optimizer, and the postmaster -d output showed the parse
and rewrite were ok, but the plan was wrong, so it had to be the
optimizer. (New debugging levels cause -d 99 to have to be used to see
the query trees.)
I then went to the optimizer and looked for a reference to OP_EXPR,
which is the new value the expression was getting. I saw it in
make_opclause(). I set a breakpoint on that function and executed the
query inside gdb. It showed only one call to the function for that
query, and a backtrace on the breakpoint showed flatten_tlistentry()
making the call, and it was clear after that.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
http://www.op.net/~candle | (610) 353-9879(w)
+ If your life is a hard drive, | (610) 853-3000(h)
+ Christ can be your backup. |
