You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix visimap consults for unique checks during UPDATEs
This fixes #17183.
When consulting the visimap during an UPDATE for the purposes of
uniqueness checks, we used to refer to the visimap from the delete half
of the update.
This is the wrong structure to look at as this structure is not meant to
be consulted while deletes are in flight (we haven't reached
end-of-delete where visibility info from the visimapDelete structure
flows into the catalog).
Instead, we should be consulting the visimapDelete structure attached to
the deleteDesc. This structure can handle visimap queries for tuples
that have visimap changes that haven't yet been persisted to the catalog
table.
The effect of not using this structure meant running into issues such
as: "attempted to update invisible tuple" when we would attempt to
persist a dirty visimap entry in AppendOnlyVisimap_IsVisible() with a
call to AppendOnlyVisimap_Store(). The dirty entry is one which was
introduced by the delete half of the update. Our existing test did not
trip this issue because the update did not need a swap-out of the
current entry. With enough data, however, the issue reproduces, as
evidenced in #17183.
Co-authored-by: Ashwin Agrawal <aashwin@vmware.com>
Reviewed-by: Haolin Wang <whaolin@vmware.com>
0 commit comments