Re: pg_upgrade project status - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: pg_upgrade project status
Date
Msg-id 1233086402.1475.59.camel@localhost
Whole thread Raw
In response to Re: pg_upgrade project status  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane píše v út 27. 01. 2009 v 14:31 -0500:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> > Merlin Moncure píše v út 27. 01. 2009 v 09:47 -0500:
> >> Just to clarify, does that mean that your patch has to be in for there
> >> to be any chance of in-place upgrade 8.4->8.5?
> 
> > Ok, There two patch in the queue for 8.5 which will bump page layout
> > version. Then we will need it.
> 
> I see nothing on the 2009-First list that requires any such thing.

There are page CRC and item alignment optimization. And If IIRC that
somebody what to modify compression? 

> In any case we've been over this ground before: we have agreed in the
> past that we'd be willing to reject/postpone patches that change on-disk
> data layout if in-place upgrade would otherwise be available.  I think
> that space reservation is extremely far down the list of "must haves"
> for getting 8.4->8.5 upgrade into place.  

If it means that we will not change Page Layout Version in 8.5 then I'm
happy. 

> You should first work on an
> update process that supports catalog changes, and get that committed.
> Once that's in place you'll have enough political capital to prevent
> changes in user data layout, and then we'd start to think about schemes
> like space reservation that could relax that ground rule.

OK. There is pg_upgrade.sh for 8.3->8.4 while I or someone develop
something better. But new solution will be at first for 8.4->8.5. 
thanks Zdenek







pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: 8.4 release planning
Next
From: Joshua Brindle
Date:
Subject: Re: 8.4 release planning