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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
