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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to