Horton

Re: vacuumdb: add --dry-run

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>, pgsql-hackers@postgresql.org
Date: 2025-12-04T21:52:03Z
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 →

  1. Add ParallelSlotSetIdle().

  2. vacuumdb: Add --dry-run.

  3. vacuumdb: Move some variables to the vacuumingOptions struct.

  4. Log a note at program start when running in dry-run mode

Attachments

On Thu, Nov 20, 2025 at 04:16:13PM -0600, Nathan Bossart wrote:
> On Thu, Nov 20, 2025 at 05:09:54PM -0500, Corey Huinker wrote:
>> I have no objections to, but I am curious about the factors that went into
>> making dry_run an independent boolean rather than part of vacopts.
> 
> My thinking was that it's closer to "echo" and "quiet" than anything in
> vacuumingOptions.  Most of that stuff seems geared towards controlling the
> precise behavior of the commands rather than the behavior of the
> application.  TBH I think it'd be fine either way.  We could probably even
> move "echo" and "quiet" into vacuumingOptions if we really wanted to.

Yeah, I'm finding myself liking the idea of moving all of these things into
vacuumingOptions so that we don't have to cart around so many bool
arguments.  Here's a new patch set that does it this way.

The remaining question in my mind is where we should let the user know that
we're in dry-run mode.  The three options I see are 1) at the beginning of
vacuumdb execution, 2) in the !quiet block for each database, and 3) in
each command (via a comment).  In v5, I've added a message to all three,
but I'm eager to hear what folks think.

-- 
nathan