Re: uninterruptable loop: concurrent delete in progress within table

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

In response to

Browse pgsql-bugs by date

  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