Re: Resurrecting pg_upgrade
От | Matthew T. O'Connor |
---|---|
Тема | Re: Resurrecting pg_upgrade |
Дата | |
Msg-id | 1071458502.6603.3.camel@zedora.zeut.net обсуждение исходный текст |
Ответ на | Re: Resurrecting pg_upgrade (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Resurrecting pg_upgrade
|
Список | pgsql-hackers |
On Sun, 2003-12-14 at 18:02, Tom Lane wrote: > "Matthew T. O'Connor" <matthew@zeut.net> writes: > > How limiting is the above? Does this mean that pg_upgrade will be > > rendered invalid if there is an on-disk representation change? Do we > > think we will make it from 7.4 -> 7.5 without on-disk changes? Do we > > think at this point most upgrades will be without on-disk changes? > > How large N will be in practice remains to be seen, of course, but I'd > expect something on the order of 4 or 5. Ok, this is what I was looking for. If we are serious about this, would it make sense to start a new policy of bumping the major version number every time an upgrade requires a dump / reload? So PostgreSQL 8.0 would be the next version with on-disk changes, all the 8.x releases would have the same on-disk format, and the next time the disk format changes, then we are on 9.0.
В списке pgsql-hackers по дате отправления: