Re: Support for REINDEX CONCURRENTLY

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Support for REINDEX CONCURRENTLY
Date: 2013-07-05 04:47:17
Message-ID: CAB7nPqQAx+qNEg1Dmao=5FEo6gwKUNziRM+mXSVxQmr0vrP8GQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

Please find attached the patch using MVCC catalogs. I have split the
previous core patch into 3 pieces to facilitate the review and reduce
the size of the main patch as the previous core patch contained a lot
of code refactoring.
0) 20130705_0_procarray.patch, this patch adds a set of generic APIs
in procarray.c that can be used to wait for snapshots older than a
given xmin, or to wait for some virtual locks. This code has been
taken from CREATE/DROP INDEX CONCURRENTLY, and I think that this set
of APIs could be used for the implementation os other concurrent DDLs.
1) 20130705_1_index_conc_struct.patch, this patch refactors a bit
CREATE/DROP INDEX CONCURRENTLY to create 2 generic APIs for the build
of a concurrent index, and the step where it is set as dead.
2) 20130705_2_reindex_concurrently_v28.patch, with the core feature. I
have added some stuff here:
- isolation tests, (perhaps it would be better to make the DML actions
last longer in those tests?)
- reduction of the lock used at swap phase from AccessExclusiveLock to
ShareUpdateExclusiveLock, and added a wait before commit of swap phase
for old snapshots at the end of swap phase to be sure that no
transactions will use the old relfilenode that has been swapped after
commit
- doc update
- simplified some APIs, like the removal of index_concurrent_clear_valid
- fixed a bug where it was not possible to reindex concurrently a toast relation
Patch 1 depends on 0, Patch 2 depends on 1 and 0. Patch 0 can be
applied directly on master.

The two first patches are pretty simple, patch 0 could even be quickly
reviewed and approved to provide some more infrastructure that could
be possibly used by some other patches around, like REFRESH
CONCURRENTLY...

I have also done some tests with the set of patches:
- Manual testing, and checked that process went smoothly by taking
some manual checkpoints during each phase of REINDEX CONCURRENTLY
- Ran make check for regression and isolation tests
- Ran make installcheck, and then REINDEX DATABASE CONCURRENTLY on the
database regression that remained on server

Regards,
--
Michael

Attachment Content-Type Size
20130705_0_procarray.patch application/octet-stream 13.6 KB
20130705_1_index_conc_struct.patch application/octet-stream 7.6 KB
20130705_2_reindex_concurrently_v28.patch application/octet-stream 63.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2013-07-05 05:02:13 Re: Proposal - Support for National Characters functionality
Previous Message Kevin Hale Boyes 2013-07-05 04:28:18 [COMMITTERS] pgsql: Add new GUC, max_worker_processes, limiting number of bgworkers.