-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
> Migration is really only half the story, or not even that much. Every
> time you move to a new Postgres version you have to do extensive work to
> revalidate your application. If you don't do that you're just asking for
> trouble. But it can be painful, expensive and disruptive. I know of
> places where it can take weeks or months of effort. So the less often
> you have to do it the better. This would be true even if we had had a
> perfect working inplace upgrade mechanism for years, which as you and
> Greg point out is not true.
I don't agree with this - migration is much more important than you make out.
Testing and validation can be a pain, but it can be done concurrently while
your main production site is still chugging along and taking orders. At some
point, however, migration *will* cause production downtime[1]. This is one of
the Achilles' heel of Postgres, and I'm frankly surprised it has taken us
this long to get pg_migrator to a somewhat working state.
> I don't have any clients who don't/can't upgrade because they can't
> manage the downtime, but I have more than one avoiding upgrade because
> of revalidation costs.
Well, I certainly had many clients who had major problems dealing with
the implicit casts removed in 8.3, but there are also some in which the
sheer size of the database is a factor as well. I think Robert Treat
can probably chime in on some upgrade woes here too.
[1] Okay, there are some tricks to work around this or severely minimize
the downtime </Bucardo_plug>, but it's still a truism that upgrading versions
is a pain and nearly always involves production downtime.
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200912040846
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAksZEqMACgkQvJuQZxSWSsgGyACdEyfIqwFsFrt9ZnQ2DNPVYIWP
j08AoK+cLC84HSjlIbzJY8Gz/gAa6D74
=AzuV
-----END PGP SIGNATURE-----
