Re: Support for REINDEX CONCURRENTLY

Hi,

Please find attached a patch fixing 3 of the 4 problems reported before
(the patch does not contain docs).
1) Removal of the quadratic dependency with list_append_unique_oid
2) Minimization of the wait phase for parent relations, this is done in a
single transaction before phase 2
3) Authorization of the drop for invalid system indexes

The problem remaining is related to toast indexes. In current master code,
tuptoastter.c assumes that the index attached to the toast relation is
unique
This creates a problem when running concurrent reindex on toast indexes,
because after phase 2, there is this problem:
pg_toast_index valid && ready
pg_toast_index_cct valid && !ready
The concurrent toast index went though index_build is set as valid. So at
this instant, the index can be used when inserting new entries.

However, when inserting a new entry in the toast index, only the index
registered in reltoastidxid is used for insertion in
tuptoaster.c:toast_save_datum.
toastidx = index_open(toastrel->rd_rel->reltoastidxid, RowExclusiveLock);
This cannot work when there are concurrent toast indexes as in this case
the toast index is thought as unique.

In order to fix that, it is necessary to extend toast_save_datum to insert
index data to the other concurrent indexes as well, and I am currently
thinking about two possible approaches:
1) Change reltoastidxid from oid type to oidvector to be able to manage
multiple toast index inserts. The concurrent indexes would be added in this
vector once built and all the indexes in this vector would be used by
tuptoaster.c:toast_save_datum. Not backward compatible but does it matter
for toast relations?
2) Add new oidvector column in pg_class containing a vector of concurrent
toast index Oids built but not validated. toast_save_datum would scan this
vector and insert entries in index if there are any present in vector.

Comments as well as other ideas are welcome.
Thanks,
--
Michael