Re: pg_upgrade project status
От | Zdenek Kotala |
---|---|
Тема | Re: pg_upgrade project status |
Дата | |
Msg-id | 1233086402.1475.59.camel@localhost обсуждение исходный текст |
Ответ на | Re: pg_upgrade project status (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: