Skip site navigation (1) Skip section navigation (2)

Re: Bug #514: Backend crashes periodically

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 (view raw or flat)
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

In response to

pgsql-bugs by date

Next:From: brunoDate: 2001-11-11 13:30:45
Subject: 7.2 doc comments
Previous:From: Warren VolzDate: 2001-11-11 03:37:22
Subject: Re: Bug #514: Backend crashes periodically

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group