Thread

  1. crash in DROP INDEX CONCURRENTLY

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2012-11-07T15:54:57Z

    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.
    
    I think the fix is just to move the heap_open calls some lines upwards, as in
    the attached patch.
    
    -- 
    Álvaro Herrera                http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Training & Services
    
  2. Re: crash in DROP INDEX CONCURRENTLY

    Andres Freund <andres@2ndquadrant.com> — 2012-11-07T19:20:55Z

    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
    
    
    
  3. Re: crash in DROP INDEX CONCURRENTLY

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2012-11-07T19:37:57Z

    Andres Freund wrote:
    > On Wed, Nov 07, 2012 at 12:54:57PM -0300, Alvaro Herrera wrote:
    
    > > I think the fix is just to move the heap_open calls some lines upwards, as in
    > > the attached patch.
    
    > Looks like the right thing to me.
    
    Pushed.
    
    -- 
    Álvaro Herrera                http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Training & Services