Re: vacuumdb: add --dry-run

Corey Huinker <corey.huinker@gmail.com>

From: Corey Huinker <corey.huinker@gmail.com>

To: Nathan Bossart <nathandbossart@gmail.com>

Cc: pgsql-hackers@postgresql.org

Date: 2025-11-10T22:33:34Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Add ParallelSlotSetIdle().
- 750816971b35 19 (unreleased) landed
vacuumdb: Add --dry-run.
- d107176d27c7 19 (unreleased) landed
vacuumdb: Move some variables to the vacuumingOptions struct.
- cf1450e57799 19 (unreleased) landed
Log a note at program start when running in dry-run mode
- c05dee191125 19 (unreleased) cited

>
>
> My attempts to test this all got stuck in wait_on_slots().  I haven't
> looked too closely, but I suspect the issue is that the socket never
> becomes readable because we don't send a query.  If I set free_slot->inUse
> to false before printing the command, it no longer hangs.  We probably want
> to create a function in parallel_slot.c to mark slots that we don't intend
> to give a query as idle.


Would that be preferable to skipping the creation of extra connections for
parallel workers? I can see it both ways. On the one hand we want to give
as true a reflection of "what would happen with these options", and on the
other hand one could view the creation of extra workers as "real" vs a dry
run.