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

Hi Michael,

On 2013-02-07 16:45:57 +0900, Michael Paquier wrote:
> Please find attached a patch fixing 3 of the 4 problems reported before
> (the patch does not contain docs).

Cool!

> 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.

> 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?

> 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.

> 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?

I think your patch accidentially squashed in some other changes (like
5a1cd89f8f), care to repost without?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services