Re: pg_upgrade (was: 8.2 features status)
От | Jim C. Nasby |
---|---|
Тема | Re: pg_upgrade (was: 8.2 features status) |
Дата | |
Msg-id | 20060804193031.GP40481@pervasive.com обсуждение исходный текст |
Ответ на | Re: pg_upgrade (was: 8.2 features status) (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: pg_upgrade (was: 8.2 features status)
Re: pg_upgrade (was: 8.2 features status) |
Список | pgsql-hackers |
On Fri, Aug 04, 2006 at 02:12:16PM -0400, Stephen Frost wrote: > * Jim C. Nasby (jnasby@pervasive.com) wrote: > > On Thu, Aug 03, 2006 at 11:20:48PM -0700, Josh Berkus wrote: > > > > * In-place upgrades (pg_upgrade) > > > > > > BTW, I may get Sun to contribute an engineer for this; will get you posted. > > > > How would such a thing handle changes to page formats? > > Couldn't this be done by converting a table/partial-table at a time? > It wouldn't be something which could run while the system is live, but > it'd probably take less time than dump/restore and wouldn't require > double the disk space of the whole database... no? True, but if you're going to go about creating code that can deal with 2 different versions of on-disk data, why not go one better: put that code into the database itself, so that pages are converted on-the-fly as they're dirtied. That way you have *no* downtime (or almost no, anyway). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-hackers по дате отправления: