From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: Bruce Momjian <bruce@momjian.us>, pgsql-hackers@postgresql.org
Subject: Re: pg_upgrade: fail early if a tablespace dir already exists for new
 cluster version
In-reply-to: <20201020230638.GI9241@telsasoft.com>
References: <20200925005531.GJ23631@telsasoft.com>
 <20201009185325.GA24870@momjian.us> <20201009192310.GS17626@telsasoft.com>
 <20201009234251.GA8419@momjian.us> <20201015233530.GG3797@momjian.us>
 <20201020230638.GI9241@telsasoft.com>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Tue, 20 Oct 2020 18:06:38 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <694457.1603243042.1@sss.pgh.pa.us>
Date: Tue, 20 Oct 2020 21:17:22 -0400
Message-ID: <694458.1603243042@sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.com> writes:
> I wonder if pg_upgrade should try to rmdir() the tablespace dirs before
> restoring global objects, allowing it to succeed, rather than just "failing
> early".

I'm a little confused about that.  If the directories aren't empty,
that will fail, but if they are, shouldn't the upgrade just work?
initdb is not normally unhappy about the target directory existing
if it's empty.

The reason why rmdir-and-recreate is not a great substitute for
"it just works" is that (a) you may lose the intended ownership or
permissions of those dirs, (b) you may lack write permission on their
parent dirs.  So cases where the DBA has pre-created the directories
are important to support.

			regards, tom lane