Jochem van Dieten <jochemd@xxxxxxxxxxxxxx> writes:
> That's different from backtracing a core dump :) This better?
> Breakpoint 1, 0x16d8f8 in elog ()
> (gdb) bt
> #0 0x16d8f8 in elog ()
> #1 0x110abb in pg_exec_query_string ()
> #2 0x112a91 in PostgresMain ()
> #3 0xf4eae in DoBackend ()
> #4 0xf463d in BackendStartup ()
> #5 0xf3040 in ServerLoop ()
> #6 0xf2502 in PostmasterMain ()
> #7 0xc9926 in main ()
Drat. I forgot that in 7.3, elog will be entered even if the message
ends up being too low-priority to be output. What you've got here is
just a routine elog(DEBUG) or elog(LOG) call ... and there are probably
a whole bunch more that will happen before the one with ERROR.
[ studies 7.3 code a bit ] It might work better to set the breakpoint at
elog_message_prefix, assuming you've got logging dialed down to the
point where only actual ERRORs go to the log. However, I'm not certain
gdb will let you do that in a backend compiled without debug support;
it may not know about elog_message_prefix since that's just a static
routine. Give it a try and see.
If that doesn't work ... can anyone think of another way to isolate the
elog(ERROR) call in a backend compiled without debug support?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
