From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Warren Volz <wrv(at)po(dot)cwru(dot)edu> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Bug #514: Backend crashes periodically |
Date: | 2001-11-11 04:02:02 |
Message-ID: | 18646.1005451322@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Warren Volz <wrv(at)po(dot)cwru(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | bruno | 2001-11-11 13:30:45 | 7.2 doc comments |
Previous Message | Warren Volz | 2001-11-11 03:37:22 | Re: Bug #514: Backend crashes periodically |