Re: New pg_upgrade data directory inside old one?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New pg_upgrade data directory inside old one?
Date: 2016-02-18 23:32:47
Message-ID: 20160218233247.GA30338@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 15, 2016 at 06:32:06PM +0100, Magnus Hagander wrote:
>
>
> On Mon, Feb 15, 2016 at 6:29 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> Someone on IRC reported that if they had run the pg_upgrade-created
> delete_old_cluster.sh shell script it would have deleted their old _and_
> new data directories.  (Fortunately they didn't run it.)
>
> I was confused how this could have happened, and the user explained that
> their old cluster was in /u/pgsql/data, and that they wanted to switch to
> a per-major-version directory naming schema, so they put the new data
> directory in /u/pgsql/data/9.5.  (They could have just moved the
> directory while the server was down, but didn't.)
>
> Unfortunately, there is no check for having the new cluster data
> directory inside the old data directory, only a check for tablespace
> directories in the old cluster.  (I never anticipated someone would do
> this.)
>
>
> Interesting - I definitely wouldn't have expected that either. And it
> definitely seems like a foot-gun we should protect the users against. 

Patch applied back through 9.3 where delete script tests were added.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2016-02-18 23:40:23 Re: Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
Previous Message Tom Lane 2016-02-18 23:06:32 Re: [HACKERS] The number of bytes is stored in index_size of pgstatindex() ?