| From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, 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:53:07 |
| Message-ID: | 48519AC3.1010209@cheapcomplexdevices.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane 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? In such a
> situation an in-place update might be impossible, and that certainly
> takes it outside the bounds of what ReadBuffer can be expected to manage.
Would a possible solution to this be that you could
1. Upgrade to the newest minor-version of the old release
(which has knowledge of the space requirements of the
new one).
2. Run some new maintenance command like "vacuum expand" or
"vacuum prepare_for_upgrade" or something that would split
any too-full pages, leaving only pages with enough space.
3. Only then shutdown the old server and start the
new major-version server.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marc Munro | 2008-06-12 22:02:20 | b64_encode and decode |
| Previous Message | Decibel! | 2008-06-12 21:39:12 | Re: Proposal: Multiversion page api (inplace upgrade) |