Re: Support for REINDEX CONCURRENTLY

On Thu, Feb 7, 2013 at 4:55 PM, Andres Freund <andres(at)2ndquadrant(dot)com>wrote:

> > 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
>
> I think there's also the issue of some minor changes required to make
> exclusion constraints work.
>
Thanks for reminding, I completely forgot this issue. I added a check with
a comment in execUtils.c:check_exclusion_constraint for that.

> > 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.
>
> Um, isn't pg_toast_index_cct !valid && ready?
>
You are right ;)

>
> > 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?
>
> I don't see a problem breaking backward compat in that area.
>
Agreed. I though so.

>
> > 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.
>
> What about
>
> 3) Use reltoastidxid if != InvalidOid and manually build the list (using
> RelationGetIndexList) otherwise? That should keep the additional
> overhead minimal and should be relatively straightforward to implement?
>
OK. Here is a new idea.

I think your patch accidentially squashed in some other changes (like
> 5a1cd89f8f), care to repost without?
>
That's... well... unfortunate... Updated version attached.
--
Michael