Re: Prevent printing "next step instructions" in initdb and pg_upgrade - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Prevent printing "next step instructions" in initdb and pg_upgrade
Date
Msg-id 20201111155305.GF12947@momjian.us
Whole thread Raw
In response to Re: Prevent printing "next step instructions" in initdb and pg_upgrade  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Prevent printing "next step instructions" in initdb and pg_upgrade  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Mon, Nov  2, 2020 at 02:23:35PM +0100, Magnus Hagander wrote:
> On Tue, Oct 27, 2020 at 12:40 PM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > On Tue, Oct 27, 2020 at 12:35:56PM +0100, Peter Eisentraut wrote:
> > > On 2020-10-27 11:53, Bruce Momjian wrote:
> > > > On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter Eisentraut wrote:
> > > > > On 2020-10-06 12:26, Magnus Hagander wrote:
> > > > > > I went with the name --no-instructions to have the same name for both
> > > > > > initdb and pg_upgrade. The downside is that "no-instructions" also
> > > > > > causes the scripts not to be written in pg_upgrade, which arguably is a
> > > > > > different thing. We could go with "--no-instructions" and
> > > > > > "--no-scripts", but that would leave the parameters different. I also
> > > > > > considered "--no-next-step", but that one didn't quite have the right
> > > > > > ring to me. I'm happy for other suggestions on the parameter names.
> > > > >
> > > > > What scripts are left after we remove the analyze script, as discussed in a
> > > > > different thread?
> > > >
> > > > There is still delete_old_cluster.sh.
> > >
> > > Well, that one can trivially be replaced by a printed instruction, too.
> >
> > True. On my system is it simply:
> >
> >         rm -rf '/u/pgsql.old/data'
> >
> > The question is whether the user is going to record the vacuumdb and rm
> > instructions that display at the end of the pg_upgrade run, or do we
> > need to write it down for them in script files.
> 
> That assumes for example that you've had no extra tablespaces defined
> in it. And it assumes your config files are actually in the same
> directory etc.
> 
> Now, pg_upgrade *could* create a script that "actually works" for most
> things, since it connects to the system and could then enumerate
> things like tablespaces and config file locations, and generate a
> script that actually uses that information.

Uh, pg_upgrade does enumerate things like tablespaces in
create_script_for_old_cluster_deletion().  I think config file locations
are beyond the scope of what we want pg_upgrade to handle.

In summary, I think the vacuumdb --analyze is now a one-line command,
but the delete part can be complex and not easily typed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee




pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pg_upgrade analyze script
Next
From: Bruce Momjian
Date:
Subject: Re: Proposition for autoname columns