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