Re: Support for REINDEX CONCURRENTLY - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support for REINDEX CONCURRENTLY
Date
Msg-id CAB7nPqQpDvD_Zc-to1jUqNzy1+rX61L8Mm-3r8RNMTDoeBsKcg@mail.gmail.com
Whole thread Raw
In response to Re: Support for REINDEX CONCURRENTLY  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Support for REINDEX CONCURRENTLY
Re: Support for REINDEX CONCURRENTLY
List pgsql-hackers
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
Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Considering Gerrit for CFs
Next
From: Pavel Stehule
Date:
Subject: Re: Considering Gerrit for CFs