Re: pg_upgrade project status
От | Tom Lane |
---|---|
Тема | Re: pg_upgrade project status |
Дата | |
Msg-id | 18325.1233162015@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade project status (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.net> writes: > * Zdenek Kotala (Zdenek.Kotala@Sun.COM) wrote: >> And very important thing is that you need old version of postgreSQL >> installed, which is something what packagers does not want. Look on >> Oracle how does it. > Just as a counter-point, Debian handles multiple concurrently installed > versions of PostgreSQL just fine, in large part to specifically deal > with the smooth migration challenge (though also because we realize > people may want to continue using the old version while others may want > to install the new version). > Not sure if that's something the community wants to encourage other > packagers to do or if we should look at making it easier to do, but it's > at least possible and has been done for a pretty large distribution. The Red Hat/Fedora brigade has also been thinking seriously about that, though we've not gotten further than thinking yet. Of course, if pg_upgrade becomes a reality we'd likely stop thinking about it. IMHO, it would not by any means be a disaster for pg_upgrade to require a copy of the older-version postmaster. The way I'd foresee packaging it is to build a separate postgresql-upgrade RPM containing pg_upgrade itself and a version-N-minus-1 postmaster that gets installed in a nonstandard location (that pg_upgrade knows about). After you've finished the upgrade you can remove that RPM and get the extra disk space back. Most of the possible alternatives mean a *permanent* disk space hit, because the postmaster will have to contain one-time-use upgrade code that can't be dropped afterwards. regards, tom lane
В списке pgsql-hackers по дате отправления: