Re: vacuumdb: add --dry-run

>
>
> 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.