Re: Python 2.5 vs the buildfarm

I notice that we now have four buildfarm members failing in the 8.1
branch, with symptoms indicating that they are running python 2.5,
which pre-8.2 plpython has known incompatibilities with. I think
it's high time we back-patched those compatibility fixes ... they've
been in the field long enough in 8.2 and 8.3 that the argument that they
pose a breakage risk seems pretty weak. Comments?

(BTW, the only reason 8.0 and 7.4 aren't failing likewise is that
there's no automated regression test for the PLs in those branches.)

regards, tom lane

On Mon, 2008-07-28 at 11:56 -0400, Tom Lane wrote:
> I notice that we now have four buildfarm members failing in the 8.1
> branch, with symptoms indicating that they are running python 2.5,
> which pre-8.2 plpython has known incompatibilities with. I think
> it's high time we back-patched those compatibility fixes ... they've
> been in the field long enough in 8.2 and 8.3 that the argument that they
> pose a breakage risk seems pretty weak. Comments?

Considering the number of users who will be running Python 2.5 in the
next six months (Debian/Ubuntu) that will still be running 8.1 (anyone
that doesn't have a need to go past 8.1), I vote +1.

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Am Monday, 28. July 2008 schrieb Tom Lane:
> I notice that we now have four buildfarm members failing in the 8.1
> branch, with symptoms indicating that they are running python 2.5,
> which pre-8.2 plpython has known incompatibilities with. I think
> it's high time we back-patched those compatibility fixes

Why would anyone running PostgreSQL 8.1 in production upgrade their stable
server to Python 2.5, and remove Python 2.4 in the process? What is the use
case, except "build farm maintainers can't keep their environments stable"?
Have we had any complaints from the field about this?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

>> I notice that we now have four buildfarm members failing in the 8.1
>> branch, with symptoms indicating that they are running python 2.5,
>> which pre-8.2 plpython has known incompatibilities with. I think
>> it's high time we back-patched those compatibility fixes

> Why would anyone running PostgreSQL 8.1 in production upgrade their stable
> server to Python 2.5, and remove Python 2.4 in the process?

Because the keep their operating system up to date, and because we still
do not have any sort of in-place upgrade.

> What is the use case, except "build farm maintainers can't keep their
> environments stable"?

What's not stable about having Python 2.5?

> Have we had any complaints from the field about this?

Probably due to lack of plpython use more than anything else, but I don't
see what the alternative is: hard-code a hack into the buildfarm code?
Keep emailing individual buildfarm members and asking them to make special
exceptions? The buildfarm is meant to test many different combinations of
factors that may or may not be seen in the field, and in this case it is
doing that job admirably.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200807290721
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkiO/bUACgkQvJuQZxSWSsissgCdFVaiZ3AvGTzCChrVa6JAAUAf
TYcAoON6x7YJm8YIJpem7KwaV/D96oSz
=ERo0
-----END PGP SIGNATURE-----

Am Tuesday, 29. July 2008 schrieb Greg Sabino Mullane:
> > Why would anyone running PostgreSQL 8.1 in production upgrade their
> > stable server to Python 2.5, and remove Python 2.4 in the process?
>
> Because the keep their operating system up to date, and because we still
> do not have any sort of in-place upgrade.

And neither does Python. Someone taking the step from Python 2.4 to 2.5 might
as well do a major upgrade of PostgreSQL as well.

> > What is the use case, except "build farm maintainers can't keep their
> > environments stable"?
>
> What's not stable about having Python 2.5?

I mean "stable" to mean "does not change (unnecessarily)". When PostgreSQL
8.1 was released, Python 2.5 was not yet out. So whoever was installing
PostgreSQL 8.1 must have done it on a system that had Python 2.4. Why not
keep that?

In fact, someone upgrading such a system would have to *rebuild* PostgreSQL.
Who does that on a production system?

> The buildfarm is meant to test many different combinations of
> factors that may or may not be seen in the field, and in this case it is
> doing that job admirably.

Yes indeed. The test results say: This combination doesn't work; use some of
these other alternatives. Why not leave it at that?

Peter Eisentraut napsal(a):
> Am Tuesday, 29. July 2008 schrieb Greg Sabino Mullane:
>>> Why would anyone running PostgreSQL 8.1 in production upgrade their
>>> stable server to Python 2.5, and remove Python 2.4 in the process?
>> Because the keep their operating system up to date, and because we still
>> do not have any sort of in-place upgrade.
>
> And neither does Python. Someone taking the step from Python 2.4 to 2.5 might
> as well do a major upgrade of PostgreSQL as well.
>
>>> What is the use case, except "build farm maintainers can't keep their
>>> environments stable"?
>> What's not stable about having Python 2.5?
>
> I mean "stable" to mean "does not change (unnecessarily)". When PostgreSQL
> 8.1 was released, Python 2.5 was not yet out. So whoever was installing
> PostgreSQL 8.1 must have done it on a system that had Python 2.4. Why not
> keep that?

+1 I think there is more important and more logical things for backporting like
system timezone patch.

Problem what I see there is that buildfarm are not stable. I think stability of
environment is one of basic requirements for buildfarm server. The major
advantages is heterogeneity of installation but if everybody update system up to
the atest version than finally we will get unified servers installation.
However, many machines are also production machines and they usually need to
update sometimes. I think that any SW upgrade should be logged. It helps to
track issues.

Zdenek

--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Tuesday, 29. July 2008 schrieb Greg Sabino Mullane:
>> What's not stable about having Python 2.5?

> I mean "stable" to mean "does not change (unnecessarily)".

I really don't understand Peter's objection here. This thread has
already consumed more person-time than I spent on applying the
back-patch. I note also that, in fact, the code that was wrong was
wrong according to pre-2.5 python as well. It accidentally failed
to fail on common architectures, but it was certainly doing things
that are undefined according to the C standard. So in my eyes this
was a bug fix.

regards, tom lane

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> Am Tuesday, 29. July 2008 schrieb Greg Sabino Mullane:
>>> What's not stable about having Python 2.5?
>
>> I mean "stable" to mean "does not change (unnecessarily)".
>
> I really don't understand Peter's objection here. This thread has
> already consumed more person-time than I spent on applying the
> back-patch.

Well I certainly wouldn't expect us to feel obligated to spend much effort
making 8.1 work with a new Redhat release, for example. We would just say 8.1
is only supported on those systems it was supported on when it was released.

But if you're happy doing the work I can't see any reason to stop you either.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I really don't understand Peter's objection here. This thread has
>> already consumed more person-time than I spent on applying the
>> back-patch.

> Well I certainly wouldn't expect us to feel obligated to spend much effort
> making 8.1 work with a new Redhat release, for example. We would just say 8.1
> is only supported on those systems it was supported on when it was released.

Well, it would certainly depend on how much effort was involved to make
it work. In this case, I drew the line at messing with autoconf ;-) ...
otherwise I might've tried to fix 7.4 as well.

regards, tom lane

On Tue, 29 Jul 2008, Peter Eisentraut wrote:

> Someone taking the step from Python 2.4 to 2.5 might as well do a major
> upgrade of PostgreSQL as well.

It takes a few seconds to upgrade Python versions, and I know I've
installed Python 2.5 from source on a production server before while not
touching anything else (after going through that process on a staging
duplicate).

How long it takes to upgrade PostgreSQL is proportional to the size of
your database, and that can easily take far longer than an acceptable
downtime window. This is how you can end up companies who are up to date
on everything else on their server, but still running an old PostgreSQL.

I once watched a company roll out a shiny new server (on the same
architecture) to improve performance, with the newer Linux distribution
required to support that hardware. But they downgraded to an older PG
version so it could still run against the existing database, on an
external array, because that was too big to dump and reload before the
system had to be back up. As Greg was pointing out, such craziness really
does happy specifically because there's no good upgrade in place mechanism
available.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Tom Lane wrote:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>
>>> I really don't understand Peter's objection here. This thread has
>>> already consumed more person-time than I spent on applying the
>>> back-patch.
>>>
>
>
>> Well I certainly wouldn't expect us to feel obligated to spend much effort
>> making 8.1 work with a new Redhat release, for example. We would just say 8.1
>> is only supported on those systems it was supported on when it was released.
>>
>
> Well, it would certainly depend on how much effort was involved to make
> it work. In this case, I drew the line at messing with autoconf ;-) ...
> otherwise I might've tried to fix 7.4 as well.
>
>
>

I think your action has been entirely appropriate.

Just to show you how wrong Peter's objection is - yesterday I found
myself having to build 7.1 so I could recover some data for a client. So
we occasionally need to build long, long after the release.

cheers

andrew

Tom Lane napsal(a):
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> Am Tuesday, 29. July 2008 schrieb Greg Sabino Mullane:
>>> What's not stable about having Python 2.5?
>
>> I mean "stable" to mean "does not change (unnecessarily)".
>
> I really don't understand Peter's objection here. This thread has
> already consumed more person-time than I spent on applying the
> back-patch. I note also that, in fact, the code that was wrong was
> wrong according to pre-2.5 python as well. It accidentally failed
> to fail on common architectures, but it was certainly doing things
> that are undefined according to the C standard. So in my eyes this
> was a bug fix.

I see. if it is small patch and also fix other problems it seems to me as
reasonable change.

Zdenek

--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql