Decision required: PostgreSQL minimum versions
Russell Keith-Magee
While we support PostgreSQL, our documentation doesn't actually
specify a minimum supported version. We have a couple of features that
are no-ops for versions prior to 8.2 (savepoints and database
autocommit), but we don't actually document a minimum required
version.
We have a specified minimum of SQLite 3.3.6 and Oracle 9i (10g for
certain features); we have a vague suggestion that MySQL 4.1 is the
minimum supported version (but we don't rule out support for 3.23 and
4.0); but what is our policy with PostgreSQL? Do we support PostgreSQL
7.4?
PostgreSQL 7.4 was released in November 2005, and will be end-of-lifed
(along with PostgreSQL 8.0) in July this year. Our usual yardstick of
slow updates, RHEL4, shipped with PostgreSQL 7.4. RHEL5 shipped with
PostgreSQL 8.1.
Why am I asking? Because of r13328. In that changeset, I added a fix
for #8901 using a database function that is available in PostgreSQL
8.0, but not in PostgreSQL 7.4.
So - I'm looking for community opinion on how to deal with this. I can
see (at least) three options:
1) Rollback the changeset, and find a PostgreSQL 7.4-compatible way
of solving the problem. Continue to support PostgreSQL 7.4, and
formally document this fact.
2) Add documentation for 1.3 that imposes a PostgreSQL 8.0 minimum;
rollback r13328, wait until the 1.3 branch is forked, and reapply to
that branch. In other words treat #8901 as a feature, rather than a
bugfix, and introduce the Python 8.0 minimum as a new restriction for
1.3, much in the same way that we dropped support for Python 2.3 in
Django 1.2.
3) Retroactively modify the documentation saying Django 1.2 required
PostgreSQL 8.0 as a minimum. This treats the absence of a documented
minimum required version as a bug, and addresses the bug by picking a
minimum supported version that. r13328 stays as is.
Our general policy for deprecating old dependencies is something we
need to have a bigger discussion about -- especially as it relates to
Python itself -- but this PostgreSQL issue is immediate and pressing.
I certainly hope that any reasoning behind the decision we make for
PostgreSQL could be generalized to answer the same question for any
other dependency.
Opinions?
Yours,
Russ Magee %-)
Andrew Godwin
So, my opnion on this is that we should drop 7.4 support, but I'm not
sure if it should be done in 1.3 or 1.2.
Firstly, from what I can find
(http://www.postgresql.org/docs/7.4/static/release-7-4.html), PostgreSQL
7.4 was released in 2003, not 2005, which puts it in the same
depreciation area as Python 2.3 (also 2003). RHEL4 itself was released
in 2005.
Given than 1.2 has dropped support for Python 2.3, and thus already
won't work on RHEL4, I see no real reason we should keep supporting 7.4,
especially if it's being EOL'd soon.
As for whether to apply the fix to 1.2 or 1.3, 1.3 seems a safer option,
but if there's no outcry from 7.4 users I'd be tempted to document 1.2
as being PostgreSQL 8.0 and up (after all, best to bundle one
RHEL4-breaking change with another). Given that it's a database, though,
people might want to keep running their old RHEL4 database boxes and
only upgrade their frontend servers, so it's definitely not easy to choose.
Still, I think option 1 is just going to hold Django back - there's a
few things they fixed in 8.0, most notably (for me) the implementation
of information_schema, which any PostgreSQL schema-altering backend is
going to want.
Andrew
Antoni Aloy
performance and utility features and it would be a pity to remain in
7.4.
--
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net
Harro
Oldest postgresql we have is 8.2.
I pity the fool who didn't upgrade !
Matt Hoskins
ticket for 8901... Andrew Godwin's reasoning above feels sound to me,
so considering that and that 1.1 would still work for postgres 7.4
users (plus my desire to see the bug in 8901 fixed sooner rather than
later as it does affect me, although I can patch django myself if I
have to wait to 1.3 so that's only minor) I'd say...
+1 on option 3
+0 on option 2
-1 on option 1
I think if the fix for 8901 isn't put into 1.2 (i.e. option 2 is
chosen) it might be worth adding a note into release notes for 1.2
about it being a known issue just because the change in m2m saves
means that users (like me) who have a combination of a longish model
name and a longish m2m field name will find things break on upgrading
from 1.1 to 1.2 so you'd want to warn them off doing so!
Matt
Jacob Kaplan-Moss
<freakb...@gmail.com> wrote:
> PostgreSQL 7.4 was released in November 2005, and will be end-of-lifed
> (along with PostgreSQL 8.0) in July this year. Our usual yardstick of
> slow updates, RHEL4, shipped with PostgreSQL 7.4. RHEL5 shipped with
> PostgreSQL 8.1.
And IIRC RedHat *will* support newer versions of PostgreSQL even on
RHEL4. I don't know a single person, even those still on RHEL4, who
are using anything under PostgreSQL 8. PostgreSQL 8.1 is easily twice
as fast as 7.4; that's usually enough to get folks to upgrade :)
> 1) Rollback the changeset, and find a PostgreSQL 7.4-compatible way
> of solving the problem. Continue to support PostgreSQL 7.4, and
> formally document this fact.
>
> 2) Add documentation for 1.3 that imposes a PostgreSQL 8.0 minimum;
> rollback r13328, wait until the 1.3 branch is forked, and reapply to
> that branch. In other words treat #8901 as a feature, rather than a
> bugfix, and introduce the Python 8.0 minimum as a new restriction for
> 1.3, much in the same way that we dropped support for Python 2.3 in
> Django 1.2.
>
> 3) Retroactively modify the documentation saying Django 1.2 required
> PostgreSQL 8.0 as a minimum. This treats the absence of a documented
> minimum required version as a bug, and addresses the bug by picking a
> minimum supported version that. r13328 stays as is.
If we'd thought of it, dropping 7.4 support in 1.2 would have been the
right thing to do. However, retroactively doing so now would be abuse
of the time machine privileges and I'd like to avoid being grounded.
#1's not worth the effort, so that just leaves #2, which sounds about
right to me.
Jacob
Matt Hoskins
> If we'd thought of it, dropping 7.4 support in 1.2 would have been the
> right thing to do. However, retroactively doing so now would be abuse
> of the time machine privileges and I'd like to avoid being grounded.
> #1's not worth the effort, so that just leaves #2, which sounds about
> right to me.
moment - that may well be just be semantics tho' as I guess anyone
who's tested it will have found it works so far :). I guess people who
are going to hit the bug in #8901 (which may be very few) when
changing from 1.1 to 1.2 will discover the problem in testing so can
hold off on migrating (or apply the patch manually), whereas people
using postgresql 7.4 may already be on version 1.2 and breaking it
working on 7.4 in a point release on 1.2.1 would be less acceptable as
they would already have moved to 1.2 and couldn't then get security
updates for 1.2 [1]
[1] Note that on django-users I did mention that it's possible to
create the function in postgresql 7.x that exists in 8 which the fix
for #8901 relies on, so they have a work around too.
Felipe Prenholato
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
--
Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://chronosbox.org/blog
Twitter: http://twitter.com/chronossc
Paul McMillan
Changing 1.2 behavior now seems like a bad idea, and Jacob's arguments
are good.
-Paul
> > .
reg...@messir.net
old code. Even 8.2 version is very-very old so it's okay to depend on
8.2+.
> While we support PostgreSQL, our documentation doesn't actually
> specify a minimum supported version. We have a couple of features that
> are no-ops for versions prior to 8.2 (savepoints and database
> autocommit), but we don't actually document a minimum required
> version.
--
wbr
Alexandre Kandalintsev
Russell Keith-Magee
Well, I need the keys to the time machine to go to the prom last
friday night, so I guess option 3 is out :-)
So - I've just committed r13348, which reverts r13328; I'll reapply
once we branch for 1.3.
Thanks to all who gave feedback.
Yours,
Russ Magee %-)
Simon Riggs
(Re-post, first post stalled)
Yeh, Django should really be moving to PostgreSQL 8.3 or above, because
of performance, administrative ease and availability of replication
features.
PostgreSQL 7.4 and 8.0 are due to be de-supported in about 1 month, 8.1
is due for de-support by end of 2010. (8.0 and 8.1 have already been
de-supported on Windows). So 8.2 is the minimum sensible version for
next release of Django, though 8.3 should be minimum recommended with
8.4 current stable release as dev target.
Happy to help with any issues arising from that move.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services
si...@2ndquadrant.com
On Jun 10, 6:53 am, Paul McMillan <P...@McMillan.ws> wrote:
> +1 for option 2.
>
> Changing 1.2 behavior now seems like a bad idea, and Jacob's arguments
> are good.
PostgreSQL...
7.4 and 8.0 are slated for de-support as soon as 9.0 is released
(soon).
8.1 is due to be de-supported about 4 months after release of 9.0 (end
of 2010).
8.2 support is due to last until the end of 2011.
There's a common misconception that the 8.x releases are somehow all
fairly similar, which is not really the case. They're all major
releases in their own right and need to be discussed separately.
On top of that, 8.2 is the earliest release that has simplified file-
based replication. 8.3 and 8.4 are the releases to recommend for
people who want decent performance. 8.3 also has some changes to
default casting between text and other datatypes which can cause some
earlier SQL to fail.
I would ask Django to move directly to 8.3 as minimum supported
version. That's the lowest release I've seen anyone use myself lately.
Current stable release is 8.4, which is the long term support version
now in later distros. 9.0 is due out shortly.
Happy to help if issues arise.
Russell Keith-Magee
There appears to be some confusion here. We're not recommending a
version of PostgreSQL that end-users should use; we're nominating the
minimum possible version that passes Django's test suite. PostgreSQL
7.4 may be bad for all sorts of reasons, but right now, all the
features of PostgreSQL that Django uses utilize are available in
PostgreSQL 7.4. When the fix for #8901 lands, this raises the bar to
PostgreSQL 8.0, but only because of the use of
pg_get_serial_sequence().
I completely agree that users would be well advised to upgrade to
PostreSQL 8.4, and there are many reasons beyond basic Django
compatibility that should drive that upgrading process. However, that
doesn't change the fact that from a purely functional perspective,
Django will work happily on PostgreSQL 8.0 (unless you want to use
database-level autocommit or savepoints, in which case the minimum
version is 8.2).
Yours,
Russ Magee %-)
Jerome Leclanche
in postgres 8.0, 8.1 and 8.2 which we *should* make available to end
users (and even enforce in some cases).
Dropping support for old dependencies is a very good thing and hell
knows how much fire this sort of thing started in Django before (cf
python2.3 support). I strongly recommend fully dropping support for
8.0 for 1.3 or 1.4, and drop support for 8.1 in the following release.
As was stated before, 8.3 is usually the oldest version users are
running.
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
Adam Nelson
Django 1.3 should feel free to go to 8.3 as a minimum Postgres if
there are db backend changes that could take advantage of those
versions' capabilities.
Ubuntu Hardy (the previous LTS) uses Postgres 8.3 and RHEL 5.5 uses
8.4.
It really seems to me that the Django project allows for underlying
databases to simply be too old. Django 1.2 will be supported until
Django 1.4 is out, so people have the option to continue using 1.2 for
a very long time if their organization has an exceedingly long upgrade
cycle internally. In my mind, people in such organizations aren't
installing Django updates until a year after the release anyway.
With that knowledge, I would personally support Django 1.3 having
minimums of Postgres 8.3 and MySQL 5.0 (again, if there is actual code
written to take advantage of those versions, not just for the hell of
it).
-Adam
Postgres Feature Matrix:
http://www.postgresql.org/about/featurematrix
MySQL 5.0.51a on Ubuntu Hardy:
http://packages.ubuntu.com/hardy/mysql-server-5.0
PostgresSQL 8.3.11 on Ubuntu Hardy:
http://packages.ubuntu.com/hardy/postgresql
Simon Riggs
> There appears to be some confusion here. We're not recommending a
> version of PostgreSQL that end-users should use; we're nominating the
> minimum possible version that passes Django's test suite. PostgreSQL
> 7.4 may be bad for all sorts of reasons, but right now, all the
> features of PostgreSQL that Django uses utilize are available in
> PostgreSQL 7.4. When the fix for #8901 lands, this raises the bar to
> PostgreSQL 8.0, but only because of the use of
> pg_get_serial_sequence().
>
> I completely agree that users would be well advised to upgrade to
> PostreSQL 8.4, and there are many reasons beyond basic Django
> compatibility that should drive that upgrading process. However, that
> doesn't change the fact that from a purely functional perspective,
> Django will work happily on PostgreSQL 8.0 (unless you want to use
> database-level autocommit or savepoints, in which case the minimum
> version is 8.2).
I take your point about the differences.
In this case, the PostgreSQL project is just about to de-support those
release levels, so that does change things somewhat. I'm not sure why it
would be useful for a future version of Django to advertise support for
a PostgreSQL version that the PostgreSQL project is itself intending to
de-support. That seems likely to cause disappointment, even though you
are correct and it will pass tests.
I am just the messenger in this, carrying goodwill between projects.
David
that's in addition to regular postgresql-server (8.1) package, not
instead of it. Postgres 8.1 is the standard version on RHEL5.x. Since
RHEL6 is based on Fedora12, I believe it will use Postgres 8.4.
Russell Keith-Magee
> On Thu, 2010-06-10 at 22:29 +0800, Russell Keith-Magee wrote:
>
>> There appears to be some confusion here. We're not recommending a
>> version of PostgreSQL that end-users should use; we're nominating the
>> minimum possible version that passes Django's test suite. PostgreSQL
>> 7.4 may be bad for all sorts of reasons, but right now, all the
>> features of PostgreSQL that Django uses utilize are available in
>> PostgreSQL 7.4. When the fix for #8901 lands, this raises the bar to
>> PostgreSQL 8.0, but only because of the use of
>> pg_get_serial_sequence().
>>
>> I completely agree that users would be well advised to upgrade to
>> PostreSQL 8.4, and there are many reasons beyond basic Django
>> compatibility that should drive that upgrading process. However, that
>> doesn't change the fact that from a purely functional perspective,
>> Django will work happily on PostgreSQL 8.0 (unless you want to use
>> database-level autocommit or savepoints, in which case the minimum
>> version is 8.2).
>
> I take your point about the differences.
>
> In this case, the PostgreSQL project is just about to de-support those
> release levels, so that does change things somewhat. I'm not sure why it
> would be useful for a future version of Django to advertise support for
> a PostgreSQL version that the PostgreSQL project is itself intending to
> de-support. That seems likely to cause disappointment, even though you
> are correct and it will pass tests.
I suppose that depends on how you interpret "advertise". Keep in mind
the reason that this issue arose in the first place -- a user had a
Django install on a VPS that provided PostgreSQL 7.4, and got bitten
by a changeset that inadvertently changed the minimum supported
version. I'm in complete agreement that this user *should* upgrade to
a newer version of PostgreSQL, but that doesn't change the fact that
Django 1.2 *did* work on PostgreSQL 7.4.
If PostgreSQL 8.0 is still officially supported by PostgreSQL, and it
works fine under Django, then there's no reason to take it off the
supported versions list. The only real reason to take something off
*our* supported version list is when supporting that version imposes
an engineering overhead that we're not willing to bear. I'm certainly
not going to put any engineering effort into supporting a version of
PostgreSQL that PostgreSQL itself isn't trying to maintain, but until
we actually need to make that call, I'm happy to "support" 8.0.
That doesn't mean we can't encourage people to use newer versions,
though. The MySQL docs already contain hints in this direction, saying
that MySQL 3.23 will probably work, but you'll have less trouble if
you use 4.1 or 5.0. I suspect a similar hint may be in order for
PostgreSQL. By the time 1.3 comes out (ETA approx Dec 2010), 8.0 and
8.1 will both be EOL, so it may be prudent to include a note to the
effect that 8.0/8.1 will "work", but they're not supported by
PostgreSQL anymore, and there are lots of advantages outside basic
Django compatibility to using 8.2+ that are well worth the effort of
upgrading.
> I am just the messenger in this, carrying goodwill between projects.
Most appreciated.
Yours,
Russ Magee %-)