Thread: [HACKERS] drop support for Python 2.3
I would like to propose that we drop support for Python 2.3. Reasons: - Python 3.6 was released in December. The list of versions we need to manage is growing. - Older Python versions are increasingly hard to build locally for testing. - It's unlikely that Python 2.3 is still used in practice. Python 2.4 is in RHEL 5, which is the typically the oldest mainstream OS we look at. - We could remove some cruft from the code. We do have buildfarm coverage on prairiedog. However, that runs a >10 year old operating system, so I think it is not representing real usage. Patch attached. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> I would like to propose that we drop support for Python 2.3.
> ...
> We do have buildfarm coverage on prairiedog. However, that runs a >10
> year old operating system, so I think it is not representing real usage.
I have no particular objection to dropping 2.3 support, but should we
make some effort to fail gracefully (ie, with a relevant error message)
on older versions? I would guess that the effect of your patch will be
to produce quite opaque failures. We seem to be computing python_version
in configure, so it shouldn't be that hard to check.
> - It's unlikely that Python 2.3 is still used in practice. Python 2.4
> is in RHEL 5, which is the typically the oldest mainstream OS we look at.
Hm, is there anything running 2.4 in the buildfarm? If we're going to
claim support for 2.4, we'd be well advised to test it.
regards, tom lane
On 2/7/17 11:49 PM, Tom Lane wrote: > Hm, is there anything running 2.4 in the buildfarm? If we're going to > claim support for 2.4, we'd be well advised to test it. It appears that we don't have anything running 2.4. A RHEL/CentOS 5 system with standard components would be a good addition to the build farm. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi, On Wed, 2017-02-08 at 09:16 -0500, Peter Eisentraut wrote: > It appears that we don't have anything running 2.4. A RHEL/CentOS 5 > system with standard components would be a good addition to the build farm. I have CentOS 5 instances running on buildfarm. I'll register them via buildfarm.pg.org soon. Regards, -- Devrim Gündüz EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
On 02/07/2017 11:49 PM, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> I would like to propose that we drop support for Python 2.3. >> ... >> We do have buildfarm coverage on prairiedog. However, that runs a >10 >> year old operating system, so I think it is not representing real usage. > I have no particular objection to dropping 2.3 support, but should we > make some effort to fail gracefully (ie, with a relevant error message) > on older versions? I would guess that the effect of your patch will be > to produce quite opaque failures. We seem to be computing python_version > in configure, so it shouldn't be that hard to check. > >> - It's unlikely that Python 2.3 is still used in practice. Python 2.4 >> is in RHEL 5, which is the typically the oldest mainstream OS we look at. > Hm, is there anything running 2.4 in the buildfarm? If we're going to > claim support for 2.4, we'd be well advised to test it. with top as (select distinct on (sysname) sysname, snapshot from build_status_recent_500 where branch = 'HEAD' orderby sysname, snapshot desc ) select * from top where exists (select 1 from build_status_log l where l.sysname = top.sysnameand l.snapshot = top.snapshot and l.branch = 'HEAD' and l.log_stage = 'config.log' and l.log_text ~ 'python2\.4'); This returns no rows. Maybe we need to set up a Centos5 or RHEL 5 animal. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2/7/17 10:49 PM, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> I would like to propose that we drop support for Python 2.3. >> ... >> We do have buildfarm coverage on prairiedog. However, that runs a >10 >> year old operating system, so I think it is not representing real usage. > I have no particular objection to dropping 2.3 support, but should we > make some effort to fail gracefully (ie, with a relevant error message) > on older versions? I would guess that the effect of your patch will be > to produce quite opaque failures. We seem to be computing python_version > in configure, so it shouldn't be that hard to check. Except AFAIK that won't protect the user if something on the OS changes and backends suddenly start loading a 2.3 library, though I guess pl/tcl suffers the same problem. BTW, the easy way to check this (at least with cypthon) would be PY_VERSION_HEX >= 0x02040000 (from cpython/include/patchlevel.h) /* Version as a single 4-byte hex number, e.g. 0x010502B2 == 1.5.2b2. Use this for numeric comparisons, e.g. #if PY_VERSION_HEX>= ... */ #define PY_VERSION_HEX ((PY_MAJOR_VERSION << 24) | \ (PY_MINOR_VERSION << 16) | \ (PY_MICRO_VERSION << 8)| \ (PY_RELEASE_LEVEL << 4) | \ (PY_RELEASE_SERIAL << 0)) -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532)
On 2/8/17 10:35, Devrim Gündüz wrote: > On Wed, 2017-02-08 at 09:16 -0500, Peter Eisentraut wrote: >> It appears that we don't have anything running 2.4. A RHEL/CentOS 5 >> system with standard components would be a good addition to the build farm. > > I have CentOS 5 instances running on buildfarm. I'll register them via > buildfarm.pg.org soon. I will wait for that before proceeding. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi Peter, On Thu, 2017-02-16 at 08:21 -0500, Peter Eisentraut wrote: > > I have CentOS 5 instances running on buildfarm. I'll register them via > > buildfarm.pg.org soon. > > I will wait for that before proceeding. Sorry for the delay. Machines are ready, I think I can prepare the buildfarm instances later Saturday. Regards, -- Devrim Gündüz EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Hi, On Thu, 2017-02-16 at 08:21 -0500, Peter Eisentraut wrote: > I will wait for that before proceeding. Sorry for the delay, I also had to build a newer flex RPM before proceeding. arapaima(x86) and aholehole(x86_64) are the new animals. They are running the buildfarm script now. Regards, -- Devrim Gündüz EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Devrim Gündüz <devrim@gunduz.org> writes:
> arapaima(x86) and aholehole(x86_64) are the new animals. They are running the
> buildfarm script now.
... and failing. I wonder what is wrong with tcl_date_week()?
Will look for the explanation in a bit.
regards, tom lane
I wrote:
> Devrim Gündüz <devrim@gunduz.org> writes:
>> arapaima(x86) and aholehole(x86_64) are the new animals. They are running the
>> buildfarm script now.
> ... and failing. I wonder what is wrong with tcl_date_week()?
> Will look for the explanation in a bit.
Relevant question: what version of tcl is installed on those?
regards, tom lane
Hi Tom, On Sun, 2017-02-19 at 10:42 -0500, Tom Lane wrote: > Relevant question: what version of tcl is installed on those? 8.4.13 is installed. Regards, -- Devrim Gündüz EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Devrim Gündüz <devrim@gunduz.org> writes:
> On Sun, 2017-02-19 at 10:42 -0500, Tom Lane wrote:
>> Relevant question: what version of tcl is installed on those?
> 8.4.13 is installed.
Hmph. I can't see any relevant-looking source changes between 8.4.13
and 8.4.15, which I have laying about here and which works fine.
I wonder if Red Hat is carrying some distro-specific patch that
breaks this case? Or conceivably it's timezone dependent?
Anyway, my inclination is just to tweak that test a bit so it doesn't
trip over the problem. The point of the test is mainly to see if the
[clock] command works at all, not to exercise any specific parameter
choices. Would you check whether this:
$ tclsh
% clock format [clock scan "1/26/2010"] -format "%U"
gives the expected result "04" on that machine?
regards, tom lane
Hi Tom, On Sun, 2017-02-19 at 13:48 -0500, Tom Lane wrote: > Hmph. I can't see any relevant-looking source changes between 8.4.13 > and 8.4.15, which I have laying about here and which works fine. > I wonder if Red Hat is carrying some distro-specific patch that > breaks this case? Just downloaded SRPM, and I don't *think* so their patch would break this. > Or conceivably it's timezone dependent? FWIW, the timezone of the server is GMT+3, if that is what you are asking. > Anyway, my inclination is just to tweak that test a bit so it doesn't > trip over the problem. The point of the test is mainly to see if the > [clock] command works at all, not to exercise any specific parameter > choices. Would you check whether this: > > $ tclsh > % clock format [clock scan "1/26/2010"] -format "%U" > > gives the expected result "04" on that machine? Yes, I got 04. Regards, -- Devrim Gündüz EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Devrim Gündüz <devrim@gunduz.org> writes:
> On Sun, 2017-02-19 at 13:48 -0500, Tom Lane wrote:
>> Or conceivably it's timezone dependent?
> FWIW, the timezone of the server is GMT+3, if that is what you are asking.
Well, that test is checking which week-of-the-year a Sunday midnight is
considered to fall into. There could be an edge-case bug in Tcl itself,
or a problem with the time zone data, or maybe if you're setting LC_TIME
to tr_TR, that changes whether weeks are considered to start on Sunday
or Monday? Although if that were the explanation I'd have expected this
test to fail in tr_TR locale on pretty much any platform. Weird.
Whatever, even if it's a bug it's not our bug. I've adjusted the test to
check the following Tuesday, so as to dodge the edge case.
regards, tom lane
Hi, On Sun, 2017-02-19 at 16:20 -0500, Tom Lane wrote: > Well, that test is checking which week-of-the-year a Sunday midnight is > considered to fall into. There could be an edge-case bug in Tcl itself, > or a problem with the time zone data, or maybe if you're setting LC_TIME > to tr_TR, that changes whether weeks are considered to start on Sunday > or Monday? Although if that were the explanation I'd have expected this > test to fail in tr_TR locale on pretty much any platform. Weird. All LC_* settings are en_GB.UTF-8 on this server. > Whatever, even if it's a bug it's not our bug. I've adjusted the test to > check the following Tuesday, so as to dodge the edge case. Thanks! Looks like buildfarm is green again. Regards, -- Devrim Gündüz EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
On 2/19/17 23:33, Devrim Gündüz wrote: > Thanks! Looks like buildfarm is green again. Thank. I have committed the patch to drop Python 2.3 support. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2/19/17 23:33, Devrim Gündüz wrote:
>> Thanks! Looks like buildfarm is green again.
> Thank. I have committed the patch to drop Python 2.3 support.
I spent some time last night building a (rather makeshift) python 2.4.1
installation on prairiedog, which I will now switch it to use in HEAD,
but keeping it pointed at 2.3 for 9.6 and older.
Based on some not-fun I had along the way to that, I think it would be
a good idea to do the Python version check a bit earlier than you have
here. The shlib search in PGAC_CHECK_PYTHON_EMBED_SETUP is pretty fragile
and version-dependent, which means that a person could waste a lot of time
trying to get past the "could not find shared library for Python" error
before being told that their Python is too old. I propose to move the
minimum-version check into _PGAC_CHECK_PYTHON_DIRS, say right after the
[Python configuration directory] stanza. Unless there was some specific
reason for not wanting it to happen in python.m4?
regards, tom lane
On 2/21/17 10:18, Tom Lane wrote: > Based on some not-fun I had along the way to that, I think it would be > a good idea to do the Python version check a bit earlier than you have > here. The shlib search in PGAC_CHECK_PYTHON_EMBED_SETUP is pretty fragile > and version-dependent, which means that a person could waste a lot of time > trying to get past the "could not find shared library for Python" error > before being told that their Python is too old. I propose to move the > minimum-version check into _PGAC_CHECK_PYTHON_DIRS, say right after the > [Python configuration directory] stanza. Unless there was some specific > reason for not wanting it to happen in python.m4? It's fine to move it. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services