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
