plperl: update ppport.h and fix configure version check

=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes:

Andres' recent post¹ about PL/Perl on Windows and linked-to² patch
containing an erroneous version check made me realise that we haven't
updated our copy of ppport.h since 2009. Attached is a patch that does
that, and applies code changes suggested by running it. I've tested
`make check-world` with `--with-perl` on both the oldest (5.8.9) and
newest (5.34.0) perls I have handy.

I haven't looked at this patch's details, but I can confirm that it
also builds and passes regression on prairiedog's 5.8.3 perl.

I also noticed that PL/Perl itself (via plc_perlboot.pl) requires Perl
5.8.1, but configure only checks for 5.8 (i.e. 5.8.0). The second patch
updates the latter to match.

Hmm ... Perl 5.8.x is old enough that probably it matters to nobody in
the real world, but if we're going to mess with this, is 5.8.1 the right
cutoff? I wonder about this because I believe prairiedog's perl to be
the oldest that we have tested in a good long while, so that we shouldn't
assert with any confidence that 5.8.1 would actually work. The last
time I surveyed the buildfarm's perl versions, in 2017, these were the
only 5.8.x animals:

Animal | Surveyed build | Configure's version report
castoroides | 2017-07-27 12:03:05 | configure: using perl 5.8.4
protosciurus | 2017-07-27 13:24:42 | configure: using perl 5.8.4
prairiedog | 2017-07-27 22:51:11 | configure: using perl 5.8.6
aholehole | 2017-07-27 19:31:40 | configure: using perl 5.8.8
anole | 2017-07-28 00:27:38 | configure: using perl 5.8.8
arapaima | 2017-07-27 19:30:52 | configure: using perl 5.8.8
gharial | 2017-07-27 20:26:16 | configure: using perl 5.8.8
locust | 2017-07-28 00:13:01 | configure: using perl 5.8.8
narwhal | 2017-03-17 05:00:02 | configure: using perl 5.8.8
gaur | 2017-07-22 21:02:43 | configure: using perl 5.8.9
pademelon | 2017-07-22 23:56:59 | configure: using perl 5.8.9

Notice that here, prairiedog is running 5.8.6, which is Apple's
vendor-installed perl on that stone-age version of macOS.
Shortly after that, I *downgraded* it to 5.8.3. I do not recall
exactly why I chose that precise perl version, but it seems
pretty likely that the reason was "I couldn't get anything older
to build".

In short: (a) we're not testing against anything older than 5.8.3
and (b) it seems quite unlikely that anybody cares about 5.8.x anyway.
So if we want to mess with this, maybe we should set the cutoff
to 5.8.3 not 5.8.1.

regards, tom lane

On 5 Oct 2021, at 05:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:

In short: (a) we're not testing against anything older than 5.8.3
and (b) it seems quite unlikely that anybody cares about 5.8.x anyway.
So if we want to mess with this, maybe we should set the cutoff
to 5.8.3 not 5.8.1.

Not being able to test against older versions in the builfarm seems like a
pretty compelling reason to set 5.8.3 as the required version.

--
Daniel Gustafsson https://vmware.com/

Daniel Gustafsson <daniel@yesql.se> writes:

On 5 Oct 2021, at 05:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:

In short: (a) we're not testing against anything older than 5.8.3
and (b) it seems quite unlikely that anybody cares about 5.8.x anyway.
So if we want to mess with this, maybe we should set the cutoff
to 5.8.3 not 5.8.1.

Not being able to test against older versions in the builfarm seems like a
pretty compelling reason to set 5.8.3 as the required version.

Looking at the list of Perl versions shipped with various OSes
(https://www.cpan.org/ports/binaries.html), bumping the minimum
requirement from 5.8.1 to 5.8.3 will affect the following OS versions,
which shipped 5.8.1 or 5.8.2:

AIX: 5.3, 6.1
Fedora: 1 (Yarrow)
macOS: 10.3 (Panther)
Redhat: 2.1
Slackware: 9.0, 9.1
OpenSUSE: 8.2

The only one of these that I can imagine we might possibly care about is
AIX, but I don't know what versions we claim to support or people
actually run PostgreSQL on (and want to upgrade to 15). The docs at
https://www.postgresql.org/docs/current/installation-platform-notes.html
just say that "AIX versions before about 6.1 […] are not recommended".

For reference, 6.1 was released on 2007-11-09 and EOL on 2017-04-30, and
7.1 was released on 2010-09-10 and is supported until 2023-04-30.

- ilmari

=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes:

Daniel Gustafsson <daniel@yesql.se> writes:

Not being able to test against older versions in the builfarm seems like a
pretty compelling reason to set 5.8.3 as the required version.

Looking at the list of Perl versions shipped with various OSes
(https://www.cpan.org/ports/binaries.html), bumping the minimum
requirement from 5.8.1 to 5.8.3 will affect the following OS versions,
which shipped 5.8.1 or 5.8.2:

AIX: 5.3, 6.1
Fedora: 1 (Yarrow)
macOS: 10.3 (Panther)
Redhat: 2.1
Slackware: 9.0, 9.1
OpenSUSE: 8.2

The only one of these that I can imagine we might possibly care about is
AIX, but I don't know what versions we claim to support or people
actually run PostgreSQL on (and want to upgrade to 15).

We do have a couple of buildfarm animals on AIX 7.1, but nothing older.
The other systems you mention are surely dead and buried.

Interestingly, although cpan's table says AIX 7.1 shipped with perl
5.10.1, what's actually on those buildfarm animals is

tgl@gcc111:[/home/tgl]which perl
/usr/bin/perl
tgl@gcc111:[/home/tgl]ls -l /usr/bin/perl
lrwxrwxrwx 1 root system 29 Nov 09 2020 /usr/bin/perl -> /usr/opt/perl5/bin/perl5.28.1

Hard to tell if that is a local update or official IBM distribution.

For reference, 6.1 was released on 2007-11-09 and EOL on 2017-04-30, and
7.1 was released on 2010-09-10 and is supported until 2023-04-30.

So 6.1 will be five years out of support by the time we release PG 15.
I'm inclined to just update the docs to say we don't support anything
older than 7.1.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

Interestingly, although cpan's table says AIX 7.1 shipped with perl
5.10.1, what's actually on those buildfarm animals is

tgl@gcc111:[/home/tgl]which perl
/usr/bin/perl
tgl@gcc111:[/home/tgl]ls -l /usr/bin/perl
lrwxrwxrwx 1 root system 29 Nov 09 2020 /usr/bin/perl -> /usr/opt/perl5/bin/perl5.28.1

Hard to tell if that is a local update or official IBM distribution.

Looks like they update the Perl version in OS updates and service packs:
https://www.ibm.com/support/pages/aix-perl-updates-and-support-perlrte

For reference, 6.1 was released on 2007-11-09 and EOL on 2017-04-30, and
7.1 was released on 2010-09-10 and is supported until 2023-04-30.

So 6.1 will be five years out of support by the time we release PG 15.

And PG 14 will be supported until nine years after the 6.1 EOL date.

I'm inclined to just update the docs to say we don't support anything
older than 7.1.

I concur.

- ilmari

=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes:

Tom Lane <tgl@sss.pgh.pa.us> writes:

Hard to tell if that is a local update or official IBM distribution.

Looks like they update the Perl version in OS updates and service packs:
https://www.ibm.com/support/pages/aix-perl-updates-and-support-perlrte

Oh, interesting. So even if someone still had AIX 6.1 in the wild,
they'd likely have some newer-than-5.8.x Perl on it.

regards, tom lane

On 10/4/21 11:12 PM, Tom Lane wrote:

In short: (a) we're not testing against anything older than 5.8.3
and (b) it seems quite unlikely that anybody cares about 5.8.x anyway.
So if we want to mess with this, maybe we should set the cutoff
to 5.8.3 not 5.8.1.

Seems OK. Note that the Msys DTK perl currawong uses to build with is
ancient (5.6.1). That's going to stay as it is until it goes completely
out of scope in about 13 months. The perl it builds plperl against is
much more modern - 5.16.3.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Andrew Dunstan <andrew@dunslane.net> writes:

Seems OK. Note that the Msys DTK perl currawong uses to build with is
ancient (5.6.1). That's going to stay as it is until it goes completely
out of scope in about 13 months. The perl it builds plperl against is
much more modern - 5.16.3.

That brings up something I was intending to ask you about -- any special
tips about running the buildfarm script with a different Perl version
than is used in the PG build itself? I'm trying to modernize a couple
of my buildfarm animals to use non-stone-age SSL, but I don't really
want to move the goalposts on what they're testing.

regards, tom lane

On 10/5/21 10:30 AM, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Seems OK. Note that the Msys DTK perl currawong uses to build with is
ancient (5.6.1). That's going to stay as it is until it goes completely
out of scope in about 13 months. The perl it builds plperl against is
much more modern - 5.16.3.

That brings up something I was intending to ask you about -- any special
tips about running the buildfarm script with a different Perl version
than is used in the PG build itself? I'm trying to modernize a couple
of my buildfarm animals to use non-stone-age SSL, but I don't really
want to move the goalposts on what they're testing.

Mostly if you set the perl you're building against in the path ahead of
the perl you running with things just work. A notable exception is TAP
tests, where you have to set PROVE in the config_env to point to the
prove script you're going to use.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

AFAICS we have consensus on doing these things (in HEAD only):

* update ppport.h to perl 5.34.0

* adjust configure and docs to set 5.8.3 as the minimum perl version

* adjust docs to say we don't test or support AIX below 7.1.

I'll go make these things happen.

regards, tom lane

I wrote:

* adjust configure and docs to set 5.8.3 as the minimum perl version

When I went to update the docs, I found they already said 5.8.3
is the minimum. Excavating in the git log led me to this old
discussion:

/messages/by-id/16894.1501392088@sss.pgh.pa.us

So it was intentional at the time to leave configure's check
as 5.8.0. However, given that the functionality available is
less than you'd expect, and that we've not tested any such
configuration in several years, I still concur with adjusting
configure to require 5.8.3. Pushed it that way just now.

regards, tom lane