my-ship-it opened a new issue, #1858:
URL: https://github.com/apache/cloudberry/issues/1858
## 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`
```c
/* 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.
```sql
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
