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 20201111162122.GH12947@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  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Wed, Nov 11, 2020 at 05:11:38PM +0100, Magnus Hagander wrote:
> > 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...

I would be worried the config file would somehow be shared between old
and new clusters.  Potentially you could use the same pg_hba.conf for
old and new, and then deleting one would stop both.  The cluster and
tablespace directories are clearly isolated to a single cluster.  I am
not sure that is 100% true of config files, or if deletion permission
would be possible for those.  It just seems too error-prone to attempt.

> 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...

Well, the question is what can the user reaonsably do.  Finding all the
tablespace subdirecties is a pain, but managing systemctl seems like
something they would already have had to deal with.  I am happy for
pg_upgrade to handle the mostly-internal parts and leave the user-facing
stuff to the user, which is what the pg_upgrade usage instructions do as
well.

> > 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.

Agreed, but I don't see OS-specific instruction on how to delete the
tablespaces as reasonable --- that should be done by pg_upgrade, and we
have had almost no complaints about that.

-- 
  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: Prevent printing "next step instructions" in initdb and pg_upgrade
Next
From: Bruce Momjian
Date:
Subject: Re: Prevent printing "next step instructions" in initdb and pg_upgrade