Re: crash in DROP INDEX CONCURRENTLY
От | Andres Freund |
---|---|
Тема | Re: crash in DROP INDEX CONCURRENTLY |
Дата | |
Msg-id | 20121107192055.GA1227@awork2 обсуждение исходный текст |
Ответ на | crash in DROP INDEX CONCURRENTLY (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: crash in DROP INDEX CONCURRENTLY
|
Список | pgsql-hackers |
On Wed, Nov 07, 2012 at 12:54:57PM -0300, Alvaro Herrera wrote: > I just observed that if I run src/test/regress' "make > installcheck-parallel" and concurrently src/test/isolation's "make > installcheck", I very reproducibly get a segfault (in an assert-enabled > build). Apparently the problem is that somebody is trying to transfer > predicate locks to a relation, but the index' relcache entry is pfreed. Yes, the location of TransferPredicateLocksToHeapRelation is bad... > I think the fix is just to move the heap_open calls some lines upwards, as in > the attached patch. > diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c > index 756f6d9..d2d91c1 100644 > --- a/src/backend/catalog/index.c > +++ b/src/backend/catalog/index.c > @@ -1475,6 +1475,8 @@ index_drop(Oid indexId, bool concurrent) > * conflicts with existing predicate locks, so now is the time to move > * them to the heap relation. > */ > + userHeapRelation = heap_open(heapId, ShareUpdateExclusiveLock); > + userIndexRelation = index_open(indexId, ShareUpdateExclusiveLock); > TransferPredicateLocksToHeapRelation(userIndexRelation); > > /* > @@ -1484,9 +1486,6 @@ index_drop(Oid indexId, bool concurrent) > */ > indexRelation = heap_open(IndexRelationId, RowExclusiveLock); > > - userHeapRelation = heap_open(heapId, ShareUpdateExclusiveLock); > - userIndexRelation = index_open(indexId, ShareUpdateExclusiveLock); > - > tuple = SearchSysCacheCopy1(INDEXRELID, > ObjectIdGetDatum(indexId)); > if (!HeapTupleIsValid(tuple)) Looks like the right thing to me. Greetings, Andres
В списке pgsql-hackers по дате отправления: