Re: Page-level version upgrade (was: Block-level CRC checks)
От | Greg Stark |
---|---|
Тема | Re: Page-level version upgrade (was: Block-level CRC checks) |
Дата | |
Msg-id | 407d949e0912021230o5f2b2606o7064eec9302b9ca9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Page-level version upgrade (was: Block-level CRC checks) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Page-level version upgrade (was: Block-level CRC checks)
|
Список | pgsql-hackers |
On Wed, Dec 2, 2009 at 6:34 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> Also, your logic seems to presume that no backports are possible to the old >> server. > > The problem on the table at the moment is that the proposed CRC > feature will expand every page by a uniform amount - so in this case a > fixed-space-per-page reservation utility would be completely adequate. > Does anyone think this is a realistic thing to backport to 8.4? This whole discussion is based on assumptions which do not match my recollection of the old discussion. I would suggest people go back and read the emails but it's clear at least some people have so it seems people get different things out of those old emails. My recollection of Tom and Heikki's suggestions for Zdenek were as follows: 1) When 8.9.0 comes out we also release an 8.8.x which contains a new guc which says to prepare for an 8.9 update. If that guc is set then any new pages are guaranteed to have enough space for 8.9.0 which could be as simple as guaranteeing there are x bytes of free space, in the case of the CRC it's actually *not* a uniform amount of free space if we go with Tom's design of having a variable chunk which moves around but it's still just a simple arithmetic to determine if there's enough free space on the page for a new tuple so it would be simple enough to backport. 2) When you want to prepare a database for upgrade you run the precheck script which first of all makes sure you're running 8.8.x and that the flag is set. Then it checks the free space on every page to ensure it's satisfactory. If not then it can do a noop update to any tuple on the page which the new free space calculation would guarantee would go to a new page. Then you have to wait long enough and vacuum. 3) Then you run pg_migrator which swaps in the new catalog files. 4) Then you shut down and bring up 8.9.0 which on reading any page *immediately* converts it to 8.9.0 format. 5) You would eventually also need some program which processes every page and guarantees to write it back out in the new format. Otherwise there will be pages that you never stop reconverting every time they're read. -- greg
В списке pgsql-hackers по дате отправления: