Re: pg_dump 8.0.3 failing against PostgreSQL 7.3.2

Jochem van Dieten <jochemd@oli.tudelft.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