ERROR: attempted to update invisible tuple, append optimized tables with updates

[danielwestermann]

ERROR: attempted to update invisible tuple, append optimized tables with updates

[ashwinstar]

Thanks for report @danielwestermann team has stared to look into the reported issue, as of now its not expected to see this error. Will provide update.

[soumyadeep2007]

The stack trace is:

heap_update_internal heapam.c:3226
simple_heap_update heapam.c:4107
CatalogTupleUpdate indexing.c:286
AppendOnlyVisimapStore_Store appendonly_visimap_store.c:156
AppendOnlyVisimap_Store appendonly_visimap.c:234
AppendOnlyVisimap_IsVisible appendonly_visimap.c:205
AppendOnlyVisimap_UniqueCheck appendonly_visimap.h:198
appendonly_index_unique_check appendonlyam_handler.c:685
table_index_unique_check tableam.h:1209
table_index_fetch_tuple_check tableam.c:213
_bt_check_unique nbtinsert.c:461
_bt_doinsert nbtinsert.c:256
btinsert nbtree.c:285
index_insert indexam.c:191
ExecInsertIndexTuples execIndexing.c:403
ExecUpdate nodeModifyTable.c:1718
ExecModifyTable nodeModifyTable.c:2689
...

[soumyadeep2007]

More minimal repro:

CREATE TABLE uao_unique_index_update_1 (a INT unique, b INT) USING ao_row DISTRIBUTED REPLICATED;
INSERT INTO uao_unique_index_update_1 SELECT a, 1 FROM generate_series (1, 32768) a;
UPDATE uao_unique_index_update_1 SET b = 2;
-- If we were to select the contents of the visimap relation on any of the
-- segments we would see 2 entries at this point, one with first_row_no = 0 and
-- the other with first_row_no = 32768.
UPDATE uao_unique_index_update_1 SET b = 3;
ERROR:  attempted to update invisible tuple  (seg0 127.0.1.1:7002 pid=1100784)

Some notes of discussion w/ @ashwinstar yesterday:

(1) The main issue is that we are trying to AppendOnlyVisimapStore_Store a visimap row in the catalog (as part of ExecUpdate() -> ... -> uniq check, that was inserted earlier as a part of the appendonly_delete() operation within appendonly_tuple_update. Said row hasn't yet been persisted into the catalog (that stuff is done in appendonly_dml_finish -> appendonly_delete_finish -> AppendOnlyVisimapDelete_Finish, so there is no chance for AppendOnlyVisimapStore_Store to find it.

Probably, we need a version of AppendOnlyVisimapDelete_Hide without the AppendOnlyVisimapEntry_HideTuple at the end.

(2) What we should be doing instead is to be using the backing visimap htab and spill file used to manage visibility info, to answer the visibility check that is a part of the uniqueness check. Calling AppendOnlyVisimap_IsVisible has the unfortunate side effect of "storing" a dirty visimap entry.

(3) Using the VisimapDelete infrastructure as mentioned in (2) is going to be a tad tricky, since that is not exposed very well at this layer.