Re: postgres 7.0.3 core dumps - Mailing list pgsql-general

From Tom Lane
Subject Re: postgres 7.0.3 core dumps
Date
Msg-id 17054.979746922@sss.pgh.pa.us
Whole thread Raw
In response to Re: postgres 7.0.3 core dumps  (Joseph Shraibman <jks@selectacast.net>)
Responses Re: Time Formats  (Jeffery L Post <postjeff@uwm.edu>)
List pgsql-general
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;

* 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...

            regards, tom lane

pgsql-general by date:

Previous
From: "Prasanth Kumar"
Date:
Subject: Re: MySQL file system
Next
From: Peter Eisentraut
Date:
Subject: Re: postgresql.conf ignored