Re: Resurrecting pg_upgrade
От | Tom Lane |
---|---|
Тема | Re: Resurrecting pg_upgrade |
Дата | |
Msg-id | 3313.1071442957@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Resurrecting pg_upgrade ("Matthew T. O'Connor" <matthew@zeut.net>) |
Ответы |
Re: Resurrecting pg_upgrade
Re: Resurrecting pg_upgrade |
Список | pgsql-hackers |
"Matthew T. O'Connor" <matthew@zeut.net> writes: >> [ pg_upgrade won't be able to change user table representation ] > 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? Per prior discussion, we will enforce some sort of limit on how often the representation of user tables/indexes can be changed. The idea will be to "batch" such changes so that you only have to do a dump/reload every N major releases instead of every one. In other words, pg_upgrade will work for most version upgrades but we reserve the right to occasionally make releases where it doesn't work. 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. In theory pg_upgrade could be made to apply changes in user data representation, but I'm unconvinced that such a process would be a big improvement over dump/reload. regards, tom lane
В списке pgsql-hackers по дате отправления: