From: | Decibel! <decibel(at)decibel(dot)org> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Zdenek Kotala" <Zdenek(dot)Kotala(at)Sun(dot)COM>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Multiversion page api (inplace upgrade) |
Date: | 2008-06-12 21:39:12 |
Message-ID: | 2803D35A-ED9D-4914-BC4D-7097D6A46DF3@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jun 11, 2008, at 10:42 AM, Heikki Linnakangas wrote:
>> Another issue is that it might not be possible to update a page for
>> lack of space. Are we prepared to assume that there will never be a
>> transformation we need to apply that makes the data bigger?
>
> We do need some solution to that. One idea is to run a pre-upgrade
> script in the old version that scans the database and moves tuples
> that would no longer fit on their pages in the new version. This
> could be run before the upgrade, while the old database is still
> running, so it would be acceptable for that to take some time.
That means old versions have to have some knowledge of new versions.
There's also a big race condition unless the old version starts
taking size requirements into account every time a page is dirtied.
> No doubt people would prefer something better than that. Another
> idea would be to have some over-sized buffers that can be used as
> the target of conversion, until some tuples are moved off to
> another page. Perhaps the over-sized buffer wouldn't need to be in
> shared memory, if they're read-only until some tuples are moved.
>
> This is pretty hand-wavy, I know. The point is, I don't think these
> problems are insurmountable.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Mayer | 2008-06-12 21:53:07 | Re: Proposal: Multiversion page api (inplace upgrade) |
Previous Message | Tom Lane | 2008-06-12 21:38:26 | Re: default client encoding in postgresql.conf |