From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Sandro Santilli <strk(at)keybit(dot)net> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: uninterruptable loop: concurrent delete in progress within table |
Date: | 2014-05-30 15:54:42 |
Message-ID: | 20140530155442.GE30516@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2014-05-30 17:33:22 +0200, Andres Freund wrote:
> > Actually, I further reduced it to not rely on PostGIS
> > and it is attached here.
>
> Thanks. I've reproduced it and I am looking at it right now.
The problem is that HeapTupleSatisfiesVacuum() doesn't really check xmax
in the TransactionIdIsInProgress(HeapTupleHeaderGetRawXmin(tuple))
case. That seems to be a longstanding omission.
Thus the case where xmin = current xid, xmax = aborted subtransaction of
the current backend isn't handled correctly an
HEAPTUPLE_DELETE_IN_PROGRESS is returned. That in turn leads to an
endless goto loop in IndexBuildHeapScan() because waiting for an aborted
xact doesn't do much good.
That itself is obviously easy to fix, but I wonder whether there aren't
other such omissions in HeapTupleSatisfiesVacuum() - from the looks of
it it wasn't originally written to support the case where the current
xact performed changes itself. Not generally unreasonable, but long
since obsolete.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2014-05-30 16:40:25 | Re: BUG #10432: failed to re-find parent key in index |
Previous Message | Andres Freund | 2014-05-30 15:33:22 | Re: uninterruptable loop: concurrent delete in progress within table |