Re: pg_upgrade

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: "Nicholson, Brad (Toronto, ON, CA)" <bnicholson(at)hp(dot)com>
Cc: Tory M Blue <tmblue(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: pg_upgrade
Date: 2011-12-05 15:24:06
Message-ID: 201112051524.pB5FO6N26949@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Nicholson, Brad (Toronto, ON, CA) wrote:
> > You mean moving tablespaces? That isn't something pg_upgrade deals
> > with. If we need docs to move tablespaces, it is a missing piece of
> > our
> > main docs, not something pg_upgrade would ever mention.
>
> If I'm reading the issue correctly, and pg_upgrade gets part way through
> an upgrade then fails if it hits a tablespace - it seems to me like
> the pg_upgrade should check for such a condition at the initial
> validation stage not proceed if found.

Checking for all such cases would make pg_upgrade huge and unusable. If
you messed up your configuration, pg_upgrade can't check for every such
case. There are thosands of ways people can mess up their configuration.

I think you should read up on how pg_upgrade attempts to be minimal:

http://momjian.us/main/blogs/pgblog/2011.html#June_15_2011_2

On a related note, Magnus is working on code for Postgres 9.2 that would
allow for easier moving of tablespaces.

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

+ It's impossible for everything to be true. +

In response to

  • Re: pg_upgrade at 2011-12-05 13:36:36 from Nicholson, Brad (Toronto, ON, CA)

Responses

  • Re: pg_upgrade at 2011-12-05 15:29:00 from Nicholson, Brad (Toronto, ON, CA)

Browse pgsql-performance by date

  From Date Subject
Next Message Nicholson, Brad (Toronto, ON, CA) 2011-12-05 15:29:00 Re: pg_upgrade
Previous Message Bruce Momjian 2011-12-05 15:19:15 Re: Intersect/Union X AND/OR