Re: pg_dump 8.0.3 failing against PostgreSQL 7.3.2

Jochem van Dieten <jochemd(at)oli(dot)tudelft(dot)nl> 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