pg_index updates and SI invalidation

While experimenting with the proposed CREATE INDEX support with
HOT, I realized that SI invalidation are not sent properly for pg_index
updates.

I noticed the following comment in relcache.c

/*
* RelationReloadClassinfo - reload the pg_class row (only)
*
* This function is used only for indexes. We currently allow only the
* pg_class row of an existing index to change (to support changes of
* owner, tablespace, or relfilenode), not its pg_index row or other
* subsidiary index schema information. Therefore it's sufficient to do
* this when we get an SI invalidation. Furthermore, there are cases
* where it's necessary not to throw away the index information, especially
* for "nailed" indexes which we are unable to rebuild on-the-fly.
*
* We can't necessarily reread the pg_class row right away; we might be
* in a failed transaction when we receive the SI notification. If so,
* RelationClearRelation just marks the entry as invalid by setting
* rd_isvalid to false. This routine is called to fix the entry when it
* is next needed.
*/

From the comment, its clear that we don't expect SI invalidation
to work correctly for pg_index row updates. We are thinking of
adding a new attribute to pg_index row to control the usability of
the index in queries. Is it worth spending time to support SI
invalidation for pg_index updates or should we rather add the
attribute to pg_class though pg_index seems to the right place ?

A side-effect of this limitation is that REINDEX does not make
an index immediately available in the same transaction if REINDEX
is used to fix an earlier failed CREATE INDEX CONCURRENTLY.
Though we set "indisvalid" to 'true' at the end of REINDEX, the
effect is not seen until the transaction completes because of
lack of SI invalidation.

Any suggestions how should I proceed with this ? Should I add
a pg_class attribute or is it worth fixing pg_index SI invalidation ?

Thanks,
Pavan

--

EnterpriseDB http://www.enterprisedb.com