On 2013-06-17 04:20:03 +0900, Fujii Masao wrote: > On Thu, Jun 6, 2013 at 1:29 PM, Michael Paquier > <michael.paquier@gmail.com> wrote: > > Hi all, > > > > Please find attached the latest versions of REINDEX CONCURRENTLY for the 1st > > commit fest of 9.4: > > - 20130606_1_remove_reltoastidxid_v9.patch, removing reltoastidxid, to allow > > a toast relation to have multiple indexes running in parallel (extra indexes > > could be created by a REINDEX CONCURRENTLY processed) > > - 20130606_2_reindex_concurrently_v26.patch, correcting some comments and > > fixed a lock in index_concurrent_create on an index relation not released at > > the end of a transaction > > Could you let me know how this patch has something to do with MVCC catalog > access patch? Should we wait for MVCC catalog access patch to be committed > before starting to review this patch?
I wondered the same. The MVCC catalog patch, if applied, would make it possible to make the actual relfilenode swap concurrently instead of requiring to take access exlusive locks which obviously is way nicer. On the other hand, that function is only a really small part of this patch, so it seems quite possible to make another pass at it before relying on mvcc catalog scans.
As mentionned by Andres, the only thing that the MVCC catalog patch can improve here
is the index swap phase (index_concurrent_swap:index.c) where the relfilenode of the
old and new indexes are exchanged. Now an AccessExclusiveLock is taken on the 2 relations
being swap, we could leverage that to ShareUpdateExclusiveLock with the MVCC catalog
access I think.
Also, with the MVCC catalog patch in, we could add some isolation tests for REINDEX CONCURRENTLY (there were some tests in one of the previous versions), what is currently not possible due to the exclusive lock taken at swap phase.
Btw, those are minor things in the patch, so I think that it would be better to not wait
for the MVCC catalog patch. Even if you think that it would be better to wait for it, you could even begin with the 1st patch allowing a toast relation to have multiple indexes (removal of reltoastidxid) which does not depend at all on it.
