From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Shruthi Gowda <gowdashru(at)gmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index |
Date: | 2023-07-13 05:26:42 |
Message-ID: | ZK+LEk8vloOlMuno@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 13, 2023 at 09:35:17AM +0530, Dilip Kumar wrote:
> Yeah, It seems that using pg_index tuples from relcache is not safe,
> at least for updating the catalog tuples. However, are there known
> rules or do we need to add some comments saying that the pg_index
> tuple from the relcache cannot be used to update the catalog tuple?
I don't recall an implied rule written in the tree about that, on top
of my mind. Perhaps something about that could be done around the
declaration of RelationData in rel.h, for instance.
> 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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-07-13 05:39:32 | Re: add non-option reordering to in-tree getopt_long |
Previous Message | Masahiko Sawada | 2023-07-13 05:25:15 | Re: doc: improve the restriction description of using indexes on REPLICA IDENTITY FULL table. |