Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index

On Thu, Jul 13, 2023 at 1:40 PM Michael Paquier <michael@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