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

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.

But getting that to cover things like removing/disabling systemd
services or init jobs or whatever the platform uses can quickly get
pretty complex I think...

I wonder if we should just not do it and just say "you should delete
the old cluster". Then we can leave it up to platform integrations to
enhance that, based on their platform knowledge (such as for example
knowing if the platform runs systemd or not). That would leave us with
both pg_upgrade and initdb printing instructions, and not scripts, and
solve that part of the issue.

Thinking further, there has been one other thing that we've talked
about before, which is to have pg_upgrade either run extension
upgrades, or generate a script that would run extension upgrades. If
we want to do that as form of a script, then we're bringing the
scripts back into play again... But maybe that's actually an argument
for *not* having pg_upgrade generate that script, but instead either
do the extension upgrades automatically, or have a separate tool that
one can run independent of pg_upgrade...

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