Re: Prototype: In-place upgrade v02
От | Zdenek Kotala |
---|---|
Тема | Re: Prototype: In-place upgrade v02 |
Дата | |
Msg-id | 48C4DF69.6090001@sun.com обсуждение исходный текст |
Ответ на | Re: Prototype: In-place upgrade v02 (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
Bruce Momjian napsal(a): > Heikki Linnakangas wrote: >> Bruce Momjian wrote: >>> As far as the page not fitting after conversion, what about some user >>> command that will convert an entire table to the new format if page >>> expansion fails. >> VACUUM? >> >> Having to run a manual command defeats the purpose somewhat, though. >> Especially if you have no way of knowing on what tables it needs to be >> run on. > > My assumption is that the page not fitting would be a rare case so > requiring something like vacuum to fix it would be OK. It is 1-2% records per heap. I assume that is is more for BTree. > What I don't want to do it to add lots of complexity to the code just to > handle the page expansion case, when such a case is rare and perhaps can > be fixed by a vacuum. Unfortunately it is not so rare. And only heap on 32bit x86 platform (4byte Max alignment) is no problem. But all index pages are affected. > >> In fact, I don't think there's any low-level data format changes yet >> between 8.3 and 8.4, so this would be a comparatively easy release to >> implement upgrade-in-place. There's just the catalog changes, but AFAICS >> nothing that would require scanning through relations. > > Yep. I did not test now but pg_upgrade.sh script worked fine in May without any modification for conversion 8.3->8.4. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql
В списке pgsql-hackers по дате отправления: