Fix visimap consults for unique checks during UPDATEs

[lss602726449]

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.

Reviewed-by: Haolin Wang whaolin@vmware.com

fix #ISSUE_Number

---

Change logs

Describe your change clearly, including what problem is being solved or what feature is being added.

If it has some breaking backward or forward compatibility, please clary.

Why are the changes needed?

Describe why the changes are necessary.

Does this PR introduce any user-facing change?

If yes, please clarify the previous behavior and the change this PR proposes.

How was this patch tested?

Please detail how the changes were tested, including manual tests and any relevant unit or integration tests.

Contributor's Checklist

Here are some reminders and checklists before/when submitting your pull request, please check them:

• Make sure your Pull Request has a clear title and commit message. You can take git-commit template as a reference.
• Sign the Contributor License Agreement as prompted for your first-time contribution(One-time setup).
• Learn the coding contribution guide, including our code conventions, workflow and more.
• List your communication in the GitHub Issues or Discussions (if has or needed).
• Document changes.
• Add tests for the change
• Pass make installcheck
• Pass make -C src/test installcheck-cbdb-parallel
• Feel free to request cloudberrydb/dev team for review and approval when your PR is ready🥳

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}