Re: postgres 7.0.3 core dumps

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

In response to

Responses

Browse pgsql-general by date

  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