Re: Proposal: Multiversion page api (inplace upgrade) - Mailing list pgsql-hackers

From Ron Mayer
Subject Re: Proposal: Multiversion page api (inplace upgrade)
Date
Msg-id 48519AC3.1010209@cheapcomplexdevices.com
Whole thread Raw
In response to Re: Proposal: Multiversion page api (inplace upgrade)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal: Multiversion page api (inplace upgrade)  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List 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.



pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Re: Proposal: Multiversion page api (inplace upgrade)
Next
From: Marc Munro
Date:
Subject: b64_encode and decode