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

On Wed, Nov 11, 2020 at 4:53 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> 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.

Ah, that's right. Forgot that it did actually handle tablespaces.

But how would config file locations be beyond the scope? WIthout that,
it's incomplete for any user using that...

And for the vast majority of users, it would for example also have to
include the un-defining of a system service (systemd, sysvinit, or
whatever) as well, which would be even more out of scope by that
argument, yet at least as important in actually deleting the old
cluster...


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

I definitely agree to that part -- my argument is that it's more
complex (or rather, more platform-specific) than can easily be put in
the script either. If it were to be replaced it wouldn't be withy "a
command",it would be with instructions basically saying "delete the
old cluster". Platform specific wrappers (debian, redhat, windows or
whatever) knows more and could do a more complete job, but trying to
make all that generic is very complicated.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/