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. +
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 |