Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?
Date
Msg-id 20190502204205.cqh6n4iznrlbqop5@alap3.anarazel.de
Whole thread Raw
In response to Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 2019-05-02 22:39:15 +0200, Peter Eisentraut wrote:
> On 2019-05-02 16:33, Andres Freund wrote:
> > And RangeVarCallbackForReindexIndex() pretty clearly sets it *heapOid:
> > 
> >          * Lock level here should match reindex_index() heap lock. If the OID
> >          * isn't valid, it means the index as concurrently dropped, which is
> >          * not a problem for us; just return normally.
> >          */
> >         *heapOid = IndexGetRelation(relId, true);
> 
> It sets it but uses it only internally.  There is no code path that
> passes in a non-zero heapOid, and there is no code path that does
> anything with the heapOid passed back out.

RangeVarGetRelidExtended() can call the callback multiple times, if
there are any concurrent schema changes. That's why it's unlocking the
previously locked heap oid.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?
Next
From: Peter Eisentraut
Date:
Subject: Re: Identity columns should own only one sequence