Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?

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