Feature: Porting unique index for AO table to CBDB

[lss602726449]

closes: #68

---

Change logs

In this PR, we mainly Port unique index for AO/AOCS table to CBDB.
Since the Memtuple in the AO table does not have the xmin and xmax attributes, we realize unique check by using its auxiliary index structure BlockDirectory (Heaptuple). Specifically, for the scenario with a unique index, when inserting into the AO table, we insert a placeholder in BlockDirectory to block the insertion of the same key. Its key design logic, see unique-index README.
Specific changes include:

1. Make changes to BlockDirectory. The previous BlockDirectory structure cannot support unique index, and the fill hole mechanism is removed.
2. Realize the insert , delete and update of the AO table in the unique index scenario
3. Add a new field version to the pg_appendonly table to distinguish it from the previous BlockDirectory structure
4. Change the vacuum implementation logic of the AO table and index. When the number of dead tuples in the segment reaches the threshold, drop the segment and recycle the segment and the corresponding index.

Why are the changes needed?

1. the previous BlockDirectory can not support unique index check
   
2. Change the vacuum implementation for more efficient vacuum

Does this PR introduce any user-facing change?

introduce for unique index for AO/AOCS

create table test (a int unique) using ao_row;
insert into test select generate_series(1,5);
insert into test values(1); --Error: duplicate key
delete from test where a = 1;
insert into test values(1); --success
update set a = 1 where a = 1; --success
vacuum test; --vacuum the segment and index 

How was this patch tested?

The main test cases are almost all cherry-picked from GP , mainly including:
isolation2: ao_blkdir, ao_unique_index, aocs_unique_index, ao_unique_index_vacuum
regress: uao_dml_unique_index_update, uao_dml_unique_index_delete, ao_unique_index_build

our changes include: ao_unique_index_vacuum
Change the test of verifying index vacuum to sequential execution. There are inconsistencies under distributed transactions during concurrent execution. For details, see bugs behind and file vaccum_ao.c

-- psql 1
CREATE EXTENSION gp_inject_fault;
CREATE TABLE unique_index_vacuum_ao_row(i int UNIQUE) USING ao_row
    DISTRIBUTED REPLICATED;
INSERT INTO unique_index_vacuum_ao_row SELECT generate_series(1, 5);
DELETE FROM unique_index_vacuum_ao_row WHERE i = 5;
SELECT gp_inject_fault('vacuum_ao_after_index_delete', 'suspend', dbid)
    FROM gp_segment_configuration WHERE role = 'p' AND content <> -1;

vacuum unique_index_vacuum_ao_row;     --execute behind the gp_wait_until_triggered_fault

--psql2
SELECT gp_wait_until_triggered_fault('vacuum_ao_after_index_delete', 1, dbid)
    FROM gp_segment_configuration WHERE role = 'p' AND content <> -1;

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.
• 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 @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 all sign our Contributor License Agreement before we can accept your contribution.
1 out of 5 committers have signed the CLA.

✅ lss602726449
❌ haolinw
❌ soumyadeep2007
❌ huansong
❌ zhihuiFan
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

Hiiii, @lss602726449 welcome!🎊 Thanks for taking the effort to make our project better! 🙌 Keep making such awesome contributions!

[yjhjstz]

support ADD CONSTRAINT ?

ALTER TABLE table_name ADD CONSTRAINT constraint_name UNIQUE (column_name);

[lss602726449]

support ADD CONSTRAINT ?

ALTER TABLE table_name ADD CONSTRAINT constraint_name UNIQUE (column_name);

Sure, almost use unique index same as heap, execpt different implementation.

[yjhjstz]

Sure, almost use unique index same as heap, execpt different implementation.

add some test like create unique index pkeys_i on pkeys (pkey1, pkey2);

[lss602726449]

Sure, almost use unique index same as heap, execpt different implementation.

add some test like create unique index pkeys_i on pkeys (pkey1, pkey2);
Thanks for your suggestion. I will add more unique test about multiple key in the next commit