Re: What does Page Layout version mean? (Was: Re: Reducing NUMERIC size for 8.3)

Since we're discussing upgrades, let me summarize the discussions we had 
over dinner in Ottawa for the benefit of all:

* pg_migrator is a sound approach to handling catalog changes.

* Handling any page format change that doesn't grow the space taken by 
data is straightforward. Note that all 8.2 -> 8.3 changes fall in this 
category.

* Page format changes that grow data size are problematic, because there 
can be pages that can't be expanded to the new format because there's 
not enough space. However, it would be possible to write a pre-upgrade 
program to look for the problematic pages, and do a dummy UPDATE on some 
tuples to move them away from such pages, to make room. The pre-upgrade 
program could be run while the old database is still up, so it doesn't 
cause downtime.

* Page format conversion can be done at upgrade time, scanning all 
relations and rewriting them. Or it can be done at runtime in ReadBuffer 
whenever a page in the old format is accessed.

We don't know what changes upcoming releases will bring, but 8.2 -> 8.3 
upgrade is feasible. Any future changes will need to be considered on a 
case-by-case basis, but we have a pretty good basic strategy that 
doesn't impose any strict restrictions on future development. Even if we 
can't guarantee that we can do a non dump/restore upgrade between every 
release, if we can do it say between every other release, that's *much* 
better than none.

As before, someone just needs to step up and do it.

Zdenek Kotala wrote:
> Andrew Sullivan wrote:
>> On Wed, Jun 20, 2007 at 12:34:21PM -0400, Robert Treat wrote:
>>> FWIW pg_migrator is a pretty good swing at an in-place upgrade tool 
>>> for 8.1->8.2.   Unfortunately until the PGDG decides that in-place 
>>> upgrade is a constraint their willing to place on development, I see 
>>> them a good chicken/egg away from making it a continually usefull tool. 
>>
>> Or maybe cart/horse.  It seems to me that the rule more likely needs
>> to be that the migrator follow the development of the database than
>> that the database engine be strongly constrained by the needs of an
>> upgrade tool.  I agree that some commitment is needed, though.
> 
> I don't think that upgrade will strongly constrain a database engine. 
> But some constrains we can expect. Any new development in some area will 
> have to take care about upgrade. If you break some "upgrade coding 
> rules" you will not to able create upgrade procedure or upgrade process 
> will be risky.
> 
> For example upgrade between 8.1 -> 8.2 is risky, because you are not 
> able easy determine what format of cidr/inet is used on the page. If 
> something fails during table structure upgrade, then it is not easy to 
> recovery from this situation.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com