Robert Haas wrote:
Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because
they necessarily want to, but they can't easily afford the downtime to
upgrade. Cutting them off arbitrarily early won't win us any friends. Once
pg_migrator (or better, in-place upgrades) is working well, we can start setting
EOL on versions based on number of years of some other criteria.
At the moment it doesn't seem likely that pg_migrator is *ever* going
to support upgrading from 7.4 or 8.0 or 8.1 to any later version.
I'm not saying that's good, but nobody's expressed much interest in
making in-place upgrade work even from an 8.2 base, let alone any
older version. For that matter, there's been no concerted effort to
resolve the limitations of the 8.3 -> 8.4 upgrade. It isn't
technically impossible for the 8.3 -> 8.5 path to be smoother than the
current 8.3 -> 8.4 path, but nobody seems excited about working on it.
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 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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
