From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joseph Shraibman <jks(at)selectacast(dot)net> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: postgres 7.0.3 core dumps |
Date: | 2001-01-17 15:55:22 |
Message-ID: | 17054.979746922@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Joseph Shraibman <jks(at)selectacast(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gordan Bobic | 2001-01-17 15:57:02 | Using max() MUCH slower in v7.1 |
Previous Message | Prasanth Kumar | 2001-01-17 15:54:52 | Re: MySQL file system |