Re: postgres 7.0.3 core dumps

Tom Lane wrote:
>
> Joseph Shraibman <jks@selectacast.net> writes:
> > Anyway I look at http://www.selectacast.net/~jks/postgres/gdb3.txt  The
> > backend was in ExecEvalVar () when it crashed.
>
> It sort of looks like the plan generated for a mergejoin must have been
> bogus, but with only routine names to go on, it's hard to tell more.
> Ways to get more info:
>
> * Recompile backend with -g (--enable-debug), so that next coredump will
> provide a more informative backtrace;
>

What do I pass into make to do this?

> * Run postmaster with -d2 so that queries are logged.  You'l need to
> have compiled with #define ELOG_TIMESTAMPS (uncomment this in
> src/include/config.h after configuring) so that log entries have PID
> identifiers, which you'll then be able to correlate to the PID of the
> crashed backend.  This'll tell us just what the failed backend had been
> doing.
>
> If it is a select from cursor that's dying, we'll really need the query
> log so that we can see what the cursor definition was...
>
From my postgres log (this wasn't from a crash, I'm just showing you
what the cursor was like):

ProcessUtility: BEGIN;
query: DECLARE cname CURSOR FOR SELECT u.userkey, u.profile, u.config,
u.rules FROM usertable u, directory d WHERE u.podkey = 2 AND u.status =
2 AND u.subper AND NOT u.banned AND u.userkey = d.userkey AND d.status
IN(2, 5);
<...>
query: FETCH 100 FROM cname;
ProcessUtility: FETCH 100 FROM cname;


>                         regards, tom lane

--
Joseph Shraibman
jks@selectacast.net
Increase signal to noise ratio.  http://www.targabot.com