Re: [GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
On Mon, Oct 6, 2008 at 9:34 AM, Markus Wanner <firstname.lastname@example.org> wrote:
> Gerfried Fuchs wrote:
>> On the
>> other hand, I still don't fully understand the problems of not being
>> able to upgrade to pg-8.3 properly. People seem to have been able to
>> upgrade from 8.1 to 8.2, so what's the real big difference between 8.1
>> vs. 8.2 and 8.2 vs. 8.3? If it's soo deep, wouldn't that mean that we
>> are having a general problem with the upgrade path here, too?
> Well, it's a general Postgres problem, not a Debian one. Upgrading
> between major versions requires a full dump/restore cycle, for which the
> downtime is proportional to the database size. For small or medium
> databases that's not an issue, but above some Gigabytes, that begins to
> hurt pretty badly.
In that case I prefer to have both db versions available and use slony
to upgrade in place. We recently upgraded from 8.1 to 8.3 and work
the downtime was measured in seconds (the time it took slony to switch
the two servers). We ran Ubuntu, but the new servers are running
Centos 5.2 mainly because that OS is more stable on our large db
server platforms while Ubuntu 8.04 was very unstable (kernel problems)
and Ubuntu 7.10 wouldn't finish an install.
> Once Postgres supports in-place upgrades between major versions, this
> issue is solved.
It has in the past but apparently the work required in coding and
testing was too much and it the upgrade in place stuff was abandoned.
Someone please correct me if I'm wrong and someone is working on it
>> And you failed to outline the
>> "enough of a reason for an exception" argument you like to brag around
> Well, at least several hours of downtime is enough of a reason for many
> people to not upgrade between major Postgres versions. It certainly is
> for us. And judging from the Postgres mailing lists, there are still
> quite some people on 7.4 just for these reasons.
Again, Slony works wonders here, if your machines can handle the
initial load produced by the slony subscription process.
> I've created Debian packages and would like to find a good way to offer
> them to the broad public via the Debian infrastructure. I'm trying to
> find out the best way to do that. End of the story.
I would think that setting up a repo would be the best way to do it.
>> By the same rule it could be argued that major version added to testing
>> should be maintained in testing for as long as can be. It's exactly the
>> same reasoning, and I guess you can see the pattern here and follow my
>> rationale outlined above.
> Uh.. that's what my first proposal was about: maintaining all major
> versions in testing.
It would seem that a diverse environment for testing would be the best
policy to pursue.