Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index
От | Dilip Kumar |
---|---|
Тема | Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index |
Дата | |
Msg-id | CAFiTN-sVL=PYXYOmpntQQ=VTzgnsQ2RvEF4GYF1GJVXQMAtYBQ@mail.gmail.com обсуждение исходный текст |
Ответ на | 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 Wed, Jul 12, 2023 at 11:12 AM Michael Paquier <michael@paquier.xyz> wrote: > > On Wed, Jul 12, 2023 at 09:38:41AM +0900, Michael Paquier wrote: > > While working recently on what has led to cfc43ae and fc55c7f, I > > really got the feeling that there could be some command sequences that > > lacked some CCIs (or CommandCounterIncrement calls) to make sure that > > the catalog updates are visible in any follow-up steps in the same > > transaction. > > Wait a minute. The validation of a partitioned index uses a copy of > the pg_index tuple from the relcache, which be out of date: > newtup = heap_copytuple(partedIdx->rd_indextuple); > ((Form_pg_index) GETSTRUCT(newtup))->indisvalid = true; But why the recache entry is outdated, does that mean that in the previous command, we missed registering the invalidation for the recache entry? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: