* Jim C. Nasby ([EMAIL PROTECTED]) wrote: > On Fri, Aug 04, 2006 at 02:12:16PM -0400, Stephen Frost wrote: > > * Jim C. Nasby ([EMAIL PROTECTED]) wrote: > > > 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).
Certainly a good idea but I'm really not sure that: a) we'd want the core server to have essentially cruft code and b) that it'd be anywhere near simple to make this actually work in the core system. Supporting two versions of the page format when the only goal is changing the formatting is quite a different thing than fully supporting two on-disk formats throughout the backend. Additionally, if you have something to convert the database wholesale then that really just needs to support 2 versions at a time, if it's piecemeal then you could end up in a situation where you have to support 3, 4, 5, however many prior page formats existed. If not then you have to have a way to force all the pages to be upgraded and you're unlikely to be able to do a whole lot more with the system while that's happening, thus adding alot of extra complication just to end up having everyone follow the 'pg_upgrade'-style path anyway... In the end though, I think once it's been done in pg_upgrade this could be revisited and considered and if enough people are interested in doing it they could probably reuse some of hte pg_upgrade code to make it happen. Thanks, Stephen
signature.asc
Description: Digital signature