From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: pg_upgrade: fail early if a tablespace dir already exists for new cluster version
Date: Tue, 20 Oct 2020 21:17:22 -0400
Message-ID: <694458.1603243042@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, pryzby@telsasoft.com, bruce@momjian.us
Subject: Re: pg_upgrade: fail early if a tablespace dir already exists for new cluster version
In-Reply-To: <694458.1603243042@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox