Horton

Re: PL_stashcache, or, what's our minimum Perl version?

Andrew Dunstan <andrew.dunstan@2ndquadrant.com>

View thread View on postgr.es
From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2017-07-28T19:01:11Z
Lists: pgsql-hackers 

On 07/28/2017 08:22 AM, Andrew Dunstan wrote:
>
> On 07/27/2017 11:58 PM, Tom Lane wrote:
>> I kinda suspect we're not actively testing non-MULTIPLICITY builds
>> either.  The 5.8.7 test I just ran was with a non-MULTIPLICITY build,
>> so the case doesn't seem actively broken, but I doubt there is any
>> buildfarm coverage.  I wonder if it'd be worth getting the buildfarm
>> to log the output of "perl -V" so we could get a clearer picture
>> of what's being tested.
>>
> It's quite possible, but in general it will need a new buildfarm client release. If you choose a few possibly critical animals we can ask the owners to apply a fairly simple patch.


Looks like this, bit it's rather tedious. I think I might back it out. I
guess I could also write it to a log file, if we really think we need it.

<https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2017-07-28%2018%3A37%3A19>

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Adjust configure to insist on Perl version >= 5.8.3.

  2. Further improve consistency of configure's program searching.

  3. Doc: specify that the minimum supported version of Perl is 5.8.3.

  4. Record full paths of programs sought by "configure".

  5. Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is