Warren Volz <wrv@po.cwru.edu> writes:
> #14 0x80c0369 in EvalPlanQual (estate=0x822ea18, rti=4,
> tid=0xbfffed28) at execMain.c:1870
The fact that the crash is down inside EvalPlanQual makes me think that
you are seeing the same problem recently reported by Barry Lind (see
pgsql-hackers archives for 5-Nov). The only way to get into
EvalPlanQual is to be trying to update/delete a tuple that was already
updated or deleted by a concurrent transaction that hasn't yet
committed. So the problem is not reproducible on a single-backend
basis --- but I think it might be fairly easy to reproduce if you
manually put two backends through the paces of your application.
Something like
Session 1 Session 2
begin;
update foo where ...
begin;
update foo where ...
[ blocks waiting for session 1 ]
end;
[ crash? ]
EvalPlanQual does work in simple test cases, so there's some extra
ingredient needed to cause the problem --- but what? If you can get
a reproducible test sequence then I'm sure we can find and fix the
error. Barry hasn't come back with a test case yet, so please work
on it...
regards, tom lane