From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Prevent printing "next step instructions" in initdb and pg_upgrade |
Date: | 2020-11-11 15:53:05 |
Message-ID: | 20201111155305.GF12947@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)momjian(dot)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(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-11-11 15:56:08 | Re: Proposition for autoname columns |
Previous Message | Magnus Hagander | 2020-11-11 15:51:27 | Re: pg_upgrade analyze script |