pg_index updates and SI invalidation - Mailing list pgsql-hackers

From Pavan Deolasee
Subject pg_index updates and SI invalidation
Date
Msg-id 2e78013d0703261027q6820df50i43a6d97ad6ff47a@mail.gmail.com
Whole thread Raw
Responses Re: pg_index updates and SI invalidation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
<br clear="all" /><br />While experimenting with the proposed CREATE INDEX support with<br />HOT, I realized that SI
invalidationare not sent properly for pg_index<br />updates.<br /><br />I noticed the following comment in relcache.c
<br/><br />/*<br /> * RelationReloadClassinfo - reload the pg_class row (only)<br /> *<br /> *  This function is used
onlyfor indexes.  We currently allow only the<br /> *  pg_class row of an existing index to change (to support changes
of<br /> *  owner, tablespace, or relfilenode), not its pg_index row or other<br /> *  subsidiary index schema
information. Therefore it's sufficient to do<br /> *  this when we get an SI invalidation.  Furthermore, there are
cases<br /> *  where it's necessary not to throw away the index information, especially<br /> *  for "nailed" indexes
whichwe are unable to rebuild on-the-fly.<br /> *<br /> *  We can't necessarily reread the pg_class row right away; we
mightbe <br /> *  in a failed transaction when we receive the SI notification.  If so,<br /> *  RelationClearRelation
justmarks the entry as invalid by setting<br /> *  rd_isvalid to false.  This routine is called to fix the entry when
it<br /> *  is next needed.<br /> */<br /><br />From the comment, its clear that we don't expect SI invalidation<br
/>towork correctly for pg_index row updates. We are thinking of<br />adding a new attribute to pg_index row to control
theusability of <br />the index in queries. Is it worth spending time to support SI<br />invalidation for pg_index
updatesor should we rather add the<br />attribute to pg_class though pg_index seems to the right place ?<br /><br />A
side-effectof this limitation is that REINDEX does not make <br />an index immediately available in the same
transactionif REINDEX<br />is used to fix an earlier failed CREATE INDEX CONCURRENTLY.<br />Though we set "indisvalid"
to'true' at the end of REINDEX, the<br /> effect is not seen until the transaction completes because of<br />lack of SI
invalidation.<br /><br />Any suggestions how should I proceed with this ? Should I add<br />a pg_class attribute or is
itworth fixing pg_index SI invalidation ? <br /><br />Thanks,<br />Pavan<br /><br />-- <br /><br />EnterpriseDB     <a
href="http://www.enterprisedb.com">http://www.enterprisedb.com</a>

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Time to package 8.2.4
Next
From: Tom Lane
Date:
Subject: Re: pg_index updates and SI invalidation