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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?
Date: 2019-05-02 20:42:05
Message-ID: 20190502204205.cqh6n4iznrlbqop5@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-05-02 20:43:47 Re: Identity columns should own only one sequence
Previous Message Peter Eisentraut 2019-05-02 20:39:15 Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?