Re: uninterruptable loop: concurrent delete in progress within table
От | Andres Freund |
---|---|
Тема | Re: uninterruptable loop: concurrent delete in progress within table |
Дата | |
Msg-id | 20140530155442.GE30516@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: uninterruptable loop: concurrent delete in progress within table (Andres Freund <andres@2ndquadrant.com>) |
Список | 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
В списке pgsql-bugs по дате отправления: