Re: Prevent printing "next step instructions" in initdb and pg_upgrade

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(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

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