Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb - Mailing list pgsql-hackers

From Tom Lane
Subject Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb
Date
Msg-id 10483.1389289464@sss.pgh.pa.us
Whole thread Raw
In response to Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I don't think this vacuumdb feature should deal with any
>> version-conversion issues.  So it sounds like the thing to do is keep the
>> wrapper script, which will give us a place to put any such special actions
>> without having to kluge up vacuumdb's behavior.  That'll avoid breaking
>> scripts that users might've built for using pg_upgrade, too.

> I guess I don't see what's wrong with kludging up vacuumdb.  It's not
> like that's a very complicated utility; what will be hurt by a few
> more options?

Carrying kluges forever, and exposing them to users' view.  The particular
example Peter gave was only relevant to upgrades from 8.4; why would we be
putting code into vacuumdb now for that, and expecting to support it
forevermore?  What if the code to fix up something doesn't even *work*
unless we're updating from version M.N?  Putting such code into vacuumdb
means you have to make it bulletproof against other invocation
circumstances, and document what it does (since it's a user-visible
switch), and just in general greatly increases the development overhead.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb
Next
From: Florian Pflug
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)