Enable parallel VACUUM (currently disabled via GPDB_14_MERGE_FIXME due to lock issues)

Summary

PostgreSQL 16's parallel VACUUM (parallel index vacuuming) is currently disabled in Cloudberry. VACUUM (PARALLEL n) is accepted syntactically, but at runtime the parallel option is silently downgraded to serial with a WARNING, on both the coordinator and every segment. The real parallel code path is compiled out.

Where

src/backend/access/heap/vacuumlazy.c:3209

/* GPDB_14_MERGE_FIXME: Don't support parallel vacuum now, we need to fix lock issues. */
if (nworkers > 0 && vacrel->do_index_vacuuming && vacrel->nindexes > 1)
    ereport(WARNING,
            (errmsg("disabling parallel option of vacuum on \"%s\" --- cannot vacuum tables in parallel",
                    vacrel->relname)));
#if 0
    else
        ...   /* the actual parallel_vacuum_init() / parallel path is #if 0'd out */

So any table with more than one index that is asked to vacuum in parallel hits this guard, and the upstream parallel path below it is dead-coded via #if 0.

Reproduction

Environment: PostgreSQL 16.9 / Apache Cloudberry 3.0.0-devel (main, c781604c5bad), 3 primary segments.

CREATE TABLE pv_demo(id int, a int, b int, c text) DISTRIBUTED BY (id);
INSERT INTO pv_demo SELECT g,g,g,md5(g::text) FROM generate_series(1,1000000) g;
CREATE INDEX ON pv_demo(a);
CREATE INDEX ON pv_demo(b);
CREATE INDEX ON pv_demo(c);
DELETE FROM pv_demo WHERE id % 3 = 0;

VACUUM (PARALLEL 3, VERBOSE) pv_demo;

Output:

WARNING:  disabling parallel option of vacuum on "pv_demo" --- cannot vacuum tables in parallel
WARNING:  disabling parallel option of vacuum on "pv_demo" --- cannot vacuum tables in parallel  (seg0 ... )
WARNING:  disabling parallel option of vacuum on "pv_demo" --- cannot vacuum tables in parallel  (seg1 ... )
WARNING:  disabling parallel option of vacuum on "pv_demo" --- cannot vacuum tables in parallel  (seg2 ... )
INFO:  finished vacuuming "postgres.public.pv_demo": index scans: 1

The vacuum completes, but serially (index scans: 1, no parallel workers launched).

Root cause

Per the in-tree comment, parallel vacuum was left disabled during the PG14→PG16 merge because of unresolved lock issues in the MPP context (parallel workers inside a QE backend vs. the segment-local locking / dispatch model). The parallel path was #if 0'd rather than adapted.

Proposed work

1. Resolve the lock issues that block backend-parallel index vacuuming inside a segment QE.
2. Re-enable the #if 0'd parallel path (parallel_vacuum_init() etc.) so VACUUM (PARALLEL n) and autovacuum can use parallel workers per segment.
3. If it cannot be supported in the MPP model, replace the silent runtime downgrade with clear documentation and, ideally, a one-time notice rather than a per-relation WARNING.

Notes

• max_parallel_maintenance_workers currently defaults to 2 but has no effect on VACUUM because of the guard above.
• Scope: heap tables with 2+ indexes. AO/AOCO tables use a different vacuum path and are out of scope for this specific guard.