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 +
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() ? |