Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index
От | Michael Paquier |
---|---|
Тема | Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index |
Дата | |
Msg-id | ZK+xfYTiiBN3lE1W@paquier.xyz обсуждение исходный текст |
Ответ на | Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index
|
Список | pgsql-hackers |
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. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: