Re: [HACKERS] Perl 5.18 breaks pl/perl regression tests?
Tom Lane wrote:
It looks quite a bit like somebody's fixed a line-counting bug inside
Perl, which may mean that we'll have to maintain two expected-output
files or else remove these particular test cases. Which would be
annoying.
Maybe we can set a $SIG{__WARN__} routine instead, which would re-print
the warning appending a \n, to supress the line count.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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
Re: [HACKERS] Perl 5.18 breaks pl/perl regression tests?
On 2013-06-03 06:55, Michael Paquier wrote: Just by having a look at the release notes of Perl, there are still nothing describing changes between 1.6.3 and 1.8.0: http://perldoc.perl.org/index-history.html That page is not updated, it seems. In this list https://metacpan.org/module/RJBS/perl-5.18.0/pod/perldelta.pod is mentioned Line numbers at the end of a string eval are no longer off by one. [perl #114658] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Perl 5.18 breaks pl/perl regression tests?
Kaare Rasmussen ka...@jasonic.dk writes: That page is not updated, it seems. In this list https://metacpan.org/module/RJBS/perl-5.18.0/pod/perldelta.pod is mentioned Line numbers at the end of a string eval are no longer off by one. [perl #114658] Hah. That leads to http://perl5.git.perl.org/perl.git/commitdiff/451f421 in which it's said What happens is that eval tacks \n; on to the end of the string if it does not already end with a semicolon. So we could likely hide the cross-version difference in behavior by adjusting these two test cases to include a semicolon in the eval'd string. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Perl 5.18 breaks pl/perl regression tests?
On Jun 3, 2013, at 7:31 AM, Tom Lane t...@sss.pgh.pa.us wrote: Hah. That leads to http://perl5.git.perl.org/perl.git/commitdiff/451f421 in which it's said What happens is that eval tacks \n; on to the end of the string if it does not already end with a semicolon. So we could likely hide the cross-version difference in behavior by adjusting these two test cases to include a semicolon in the eval'd string. And a comment, since that is, shall we say, rather obscure. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Perl 5.18 breaks pl/perl regression tests?
Buildfarm member anchovy has been failing the pl/perl regression tests
for the last 11 days. Since configure is helpful enough to print the
version number of the Perl it finds, we can see that anchovy's Perl
version was 5.16.3 in its last successful run, but it's been using
5.18.0 in all the failed runs. The output differences are:
*** /home/pgfarm/build/HEAD/pgsql.702/src/pl/plperl/expected/plperl.out Thu May
23 00:23:22 2013
--- /home/pgfarm/build/HEAD/pgsql.702/src/pl/plperl/results/plperl.out Thu May
23 00:36:31 2013
***
*** 627,633
CONTEXT: PL/Perl anonymous code block
-- check that eval is allowed and eval'd restricted ops are caught
DO $$ eval q{chdir '.'}; warn Caught: $@; $$ LANGUAGE plperl;
! WARNING: Caught: 'chdir' trapped by operation mask at line 2.
CONTEXT: PL/Perl anonymous code block
-- check that compiling do (dofile opcode) is allowed
-- but that executing it for a file not already loaded (via require) dies
--- 627,633
CONTEXT: PL/Perl anonymous code block
-- check that eval is allowed and eval'd restricted ops are caught
DO $$ eval q{chdir '.'}; warn Caught: $@; $$ LANGUAGE plperl;
! WARNING: Caught: 'chdir' trapped by operation mask at line 1.
CONTEXT: PL/Perl anonymous code block
-- check that compiling do (dofile opcode) is allowed
-- but that executing it for a file not already loaded (via require) dies
==
*** /home/pgfarm/build/HEAD/pgsql.702/src/pl/plperl/expected/plperl_init.out
Thu May 23 00:23:22 2013
--- /home/pgfarm/build/HEAD/pgsql.702/src/pl/plperl/results/plperl_init.out
Thu May 23 00:36:32 2013
***
*** 9,14
(1 row)
DO $$ warn 42 $$ language plperl;
! ERROR: 'system' trapped by operation mask at line 2.
CONTEXT: while executing plperl.on_plperl_init
PL/Perl anonymous code block
--- 9,14
(1 row)
DO $$ warn 42 $$ language plperl;
! ERROR: 'system' trapped by operation mask at line 1.
CONTEXT: while executing plperl.on_plperl_init
PL/Perl anonymous code block
Now, maybe I'm missing something, but the actual outputs look saner than
the expected outputs --- surely, by any reasonable counting method,
those error locations are indeed in line 1 of the plperl code blocks.
So why do we have line 2 in the expected output, and why are all the
other machines happy with that?
Can anyone else replicate this change of behavior? Is there anything
about it in the Perl release notes?
It looks quite a bit like somebody's fixed a line-counting bug inside
Perl, which may mean that we'll have to maintain two expected-output
files or else remove these particular test cases. Which would be
annoying.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Perl 5.18 breaks pl/perl regression tests?
On Mon, Jun 3, 2013 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote: Can anyone else replicate this change of behavior? Yes. I could reproduce that on an Archlinux box after updating to perl 1.8.0. hamster might also fail with the same error, I just updated its perl from 1.6.3 to 1.8.0. Is there anything about it in the Perl release notes? Just by having a look at the release notes of Perl, there are still nothing describing changes between 1.6.3 and 1.8.0: http://perldoc.perl.org/index-history.html It looks quite a bit like somebody's fixed a line-counting bug inside Perl, which may mean that we'll have to maintain two expected-output files or else remove these particular test cases. Which would be annoying. +1 for adding some new expected output files. -- Michael
