Re: remove spurious CREATE INDEX CONCURRENTLY wait

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, James Coleman <jtc331(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: remove spurious CREATE INDEX CONCURRENTLY wait
Date: 2020-11-27 16:53:07
Message-ID: 20201127165307.GA13721@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Actually, I noticed two things. The first of them, addressed in this
new version of the patch, is that REINDEX CONCURRENTLY is doing a lot of
repetitive work by reopening each index and table in the build/validate
loops, so that they can report progress. This is easy to remedy by
adding a couple more members to the new struct (which I also renamed to
ReindexIndexInfo), for tableId and amId. The code seems a bit simpler
this way.

The other thing is that ReindexRelationConcurrenty seems to always be
called with the relations already locked by RangeVarGetRelidExtended.
So claiming to acquire locks on the relations over and over is
pointless. (I only noticed this because there was an obvious deadlock
hazard in one of the loops, that locked index before table.) I think we
should reduce all those to NoLock. My patch does not do that.

Attachment Content-Type Size
reindex-concurrently-2.patch text/x-diff 15.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2020-11-27 16:56:31 Re: proposal: possibility to read dumped table's name from file
Previous Message Heikki Linnakangas 2020-11-27 16:49:57 Re: Removing unneeded self joins