Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Shruthi Gowda <gowdashru@gmail.com>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2023-07-12T00:38:41Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add indisreplident to fields refreshed by RelationReloadIndexInfo()
- db9813819fe8 11.21 landed
- 7d27493b74c5 12.16 landed
- bdaaf1bf1d90 13.12 landed
- 7af65523ab8b 14.9 landed
- eb3abec4b67d 15.4 landed
- 27da47122075 16.0 landed
- a5ea825f958c 17.0 landed
-
Fix updates of indisvalid for partitioned indexes
- ed2b58c153bc 11.21 landed
- f1d6bcdd8fb5 12.16 landed
- c89d74c18b50 13.12 landed
- 954cc2139c03 14.9 landed
- c0dc97c7bfd1 15.4 landed
- 31f9d41d625d 16.0 landed
- 38ea6aa90e61 17.0 landed
On Tue, Jul 11, 2023 at 10:52:16PM +0530, Shruthi Gowda wrote: > While testing some use cases, I encountered 'ERROR: attempted to update > invisible tuple' when a partitioned index is attached to a parent index > which is also a replica identity index. > Below is the reproducible test case. The issue is seen only when the > commands are executed inside a transaction. Thanks for the report, reproduced here. > The 'ALTER INDEX pk_foo ATTACH PARTITION foo_2023_id_ts_ix' returns > "*ERROR: attempted to update invisible tuple"* 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. > The 'indisreplident' is false, the ctid field value is old and it does > not reflect the ctid changes made by 'ALTER TABLE ONLY foo REPLICA > IDENTITY USING INDEX pk_foo'. Your report is telling that we are missing a CCI somewhere in this sequence. I would have thought that relation_mark_replica_identity() is the correct place when the pg_index entry is dirtied, but that does not seem correct. Hmm. -- Michael