Re: pg_upgrade - Mailing list pgsql-performance

From Nicholson, Brad (Toronto, ON, CA)
Subject Re: pg_upgrade
Date
Msg-id EC55DC235432104F8255702A8D7344D9257002D4@G9W0741.americas.hpqcorp.net
Whole thread Raw
In response to Re: pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
List pgsql-performance
> -----Original Message-----
> From: Bruce Momjian [mailto:bruce@momjian.us]
> Sent: Monday, December 05, 2011 10:24 AM
> To: Nicholson, Brad (Toronto, ON, CA)
> Cc: Tory M Blue; pgsql-performance@postgresql.org; Magnus Hagander
> Subject: Re: [PERFORM] pg_upgrade
>
> 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.

Based on the OP this does not seem like a messed up configuration.  It sounds like the OP used a fully supported core
featureof Postgres (tablespaces) and pg_upgrade failed as a result.  I think having our upgrade utility fail under such
circumstancesis a bad thing. 

Brad.

pgsql-performance by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade