On Thu, Jul 13, 2023 at 1:40 PM Michael Paquier <mich...@paquier.xyz> wrote:
> On Thu, Jul 13, 2023 at 02:26:42PM +0900, Michael Paquier wrote: > > On Thu, Jul 13, 2023 at 09:35:17AM +0530, Dilip Kumar wrote: > >> Or do we actually need to update all the tuple header information as > >> well in RelationReloadIndexInfo() in order to fix that invariant so > >> that it can be used for catalog tuple updates as well? > > > > RelationReloadIndexInfo() is designed to be minimal, so I am not > > really excited about extending it more than necessary without a case > > in favor of it. indisreplident is clearly on the list of things to > > update in this concept. The others would need a more careful > > evaluation, though we don't really have a case for doing more, IMO, > > particularly in the score of stable branches. > > FYI, I was planning to do something about this thread in the shape of > two different patches: one for the indisreplident missing from the > RelationReloadIndexInfo() and one for the syscache issue in the > partitioned index validation. indisreplident use in the backend code > is interesting, as, while double-checking the code, I did not find a > code path involving a command where indisreplident would be checked > from the pg_index tuple in the relcache: all the values are from > tuples retrieved from the syscache. > Agree with the idea of splitting the patch. While analyzing the issue I did notice that validatePartitionedIndex() is the only place where the index tuple was copied from rel->rd_indextuple however was not clear about the motive behind it. Regards, Shruthi KC EnterpriseDB: http://www.enterprisedb.com
