[Pkg-postgresql-public] Postgres major version support policy on Debian

[Markus Wanner]

Hi,

Gerfried Fuchs wrote:
>  Alright, so it was actually my own fault to have done the pg-8.2
> backports, and I'm sorry for have followed the request to do so.

Don't be sorry. I still appreciate having an up to date Postgres version
available on etch. (And I still think it's the right thing to support
multiple major versions.)

> 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.

Another problem also mentioned in the cited threads is that of custom
built or contrib modules which are often problematic (i.e. costly to
adjust) to upgrade as well.

Once Postgres supports in-place upgrades between major versions, this
issue is solved.

>>> I'm providing upgraded packages for Postgres 8.2 on my own website [1].
>>> There are certainly other people who have run into the same issue, see
>>> for example [2] who dislikes using Postgres backports for exactly that
>>> reason.
> 
>  Erm, the referenced mail [2] refers to your own mail, so using that as
> a reasoning argument is a bit fishy ...

Uhm.. I'm mistyping sometimes, but not this time. [2] references:
http://archives.postgresql.org/message-id/48E48822.5060009@usit.uio.no

Which is certainly not from me.

> And you failed to outline the
> "enough of a reason for an exception" argument you like to brag around
> with.

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.

>>> On the backports-users mailing list I've requested that Postgres 8.2
>>> gets re-added to etch-backports, with upgraded packages. So that
>>> existing installations can get bug- and security fixes for that Postgres
>>> versions. One argument for rejection [3] has been, that Postgres 8.2 is
>>> not in testing anymore and can thus not be backported. I'm arguing that
>>> Postgres 8.2 is a backport per se. Not from testing, but a backport of
>>> newer software to etch.
> 
>  Your argument might be valid, but it doesn't play for backports. It was
> always clear that backports.org is about backporting packages from
> testing.

Okay, that's fine.

In that case, 8.2 should never have been backported. And very likely 8.4
shouldn't be backported either. Which is a pity IMO, and justifies an
exception of such a rule.

Note that I'm not just complaining, but offering to help and do better
myself: I continue to maintain "backports" of 8.2.

>  Backports.org is not the standard Debian infrastructure. And even if it
> were, you should this rather bring it up e.g. debian-project list.

That's why I'm cross-posting this, yes.

> Having a rule like that would though mean that an ancient version would
> never be able to get removed anywhere at all,

No. The Debian project could perfectly well drop it as soon as upstream
drops support for it (which has often been around five years after the
initial release, so far).

Note that these are bugfixes only and backporting those is certainly as
much work as supporting a new major version. Often enough, this should
just mean upgrading the sources, without having to adjust anything
debian specific.

> and would mean that the
> postgres project decides what the volunteers within the Debian project
> has to do. This doesn't work, and I would be highly surprised if the
> PostgreSQL team would actually follow that reasoning, one could argue
> the other way round too, and I'm quite sure that the postgresql team
> wouldn't be happy to be told by any other project about how and what
> they have to do.

Nobody is telling anyone else what to do here.

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.

>  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.

> That would also mean that you want postgresql 8.3 out of backports.org?
> Is this really your approach?

Well, it's pretty sure by now that Postgres 8.3 will be shipped with lenny.

> I'm sorry to have done the addition of pg 8.2 initially, and propably
> should also be sorry for adding pg 8.3 to backports.org, I thought it
> would be a service to the users, but if it seems to cause more headaches
> for some people than benefits I propably will have to take the
> consequences and refrain from doing the packages for lenny-backports and
> do them just for myself privately again.

Again, please don't be sorry. I appreciated having 8.2 (and now 8.3)
available from the backports. So do lots of other users, AFAICT.

However, silently removing a major version is not an option, IMO.

Regards

Markus Wanner