pgsql: Refactor Perl test code

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

Refactor Perl test code

This has broken "make check-world" for me (on RHEL 6.7):

make -C src/bin check
make[1]: Entering directory `/home/postgres/pgsql/src/bin'
make -C initdb check
make[2]: Entering directory `/home/postgres/pgsql/src/bin/initdb'
rm -rf /home/postgres/pgsql/src/bin/initdb/tmp_check/log
cd . && TESTDIR='/home/postgres/pgsql/src/bin/initdb' PATH="/home/postgres/pgsql/tmp_install/home/postgres/testversion/bin:$PATH" LD_LIBRARY_PATH="/home/postgres/pgsql/tmp_install/home/postgres/testversion/lib" PGPORT='65440' PG_REGRESS='/home/postgres/pgsql/src/bin/initdb/../../../src/test/regress/pg_regress' prove -I ../../../src/test/perl/ --verbose t/*.pl
t/001_initdb.pl ..
1..14
ok 1 - initdb --help exit code 0
ok 2 - initdb --help goes to stdout
ok 3 - initdb --help nothing to stderr
ok 4 - initdb --version exit code 0
ok 5 - initdb --version goes to stdout
ok 6 - initdb --version nothing to stderr
ok 7 - initdb with invalid option nonzero exit code
ok 8 - initdb with invalid option prints error message
# Looks like you planned 14 tests but ran 8.
# Looks like your test exited with 25 just after 8.
Dubious, test returned 25 (wstat 6400, 0x1900)
Failed 6/14 subtests

Test Summary Report
-------------------
t/001_initdb.pl (Wstat: 6400 Tests: 8 Failed: 0)
Non-zero exit status: 25
Parse errors: Bad plan. You planned 14 tests but ran 8.
Files=1, Tests=8, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.08 cusr 0.01 csys = 0.11 CPU)
Result: FAIL
make[2]: *** [check] Error 1
make[2]: Leaving directory `/home/postgres/pgsql/src/bin/initdb'
make[1]: *** [check-initdb-recurse] Error 2
make[1]: Leaving directory `/home/postgres/pgsql/src/bin'
make: *** [check-world-src/bin-recurse] Error 2

The buildfarm looks pretty unhappy too, though I've not checked to see if
it's exactly the same symptom everywhere.

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

On Thu, Dec 3, 2015 at 8:38 AM, Tom Lane wrote:

Test Summary Report
-------------------
t/001_initdb.pl (Wstat: 6400 Tests: 8 Failed: 0)
Non-zero exit status: 25
Parse errors: Bad plan. You planned 14 tests but ran 8.
Files=1, Tests=8, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.08 cusr 0.01 csys = 0.11 CPU)
Result: FAIL
make[2]: *** [check] Error 1
make[2]: Leaving directory `/home/postgres/pgsql/src/bin/initdb'
make[1]: *** [check-initdb-recurse] Error 2
make[1]: Leaving directory `/home/postgres/pgsql/src/bin'
make: *** [check-world-src/bin-recurse] Error 2

The buildfarm looks pretty unhappy too, though I've not checked to see if
it's exactly the same symptom everywhere.

Or in more details:
Undefined subroutine &TestLib::run called at
/Users/mpaquier/git/postgres/src/bin/initdb/../../../src/test/perl/TestLib.pm
line 146.
I am seeing the same failure on all the machines in the buildfarm.

The issue is fixed by the patch attached. This has been visibly
forgotten in the version pushed.
Regards,
--
Michael

Michael Paquier wrote:

Or in more details:
Undefined subroutine &TestLib::run called at
/Users/mpaquier/git/postgres/src/bin/initdb/../../../src/test/perl/TestLib.pm
line 146.
I am seeing the same failure on all the machines in the buildfarm.

The issue is fixed by the patch attached. This has been visibly
forgotten in the version pushed.

Yeah. Pushed.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Michael Paquier wrote:

The issue is fixed by the patch attached. This has been visibly
forgotten in the version pushed.

Yeah. Pushed.

"make check-world" passes again here. Thanks.

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Michael Paquier <michael.paquier@gmail.com> writes:

On Thu, Dec 3, 2015 at 8:38 AM, Tom Lane wrote:

Test Summary Report
-------------------
t/001_initdb.pl (Wstat: 6400 Tests: 8 Failed: 0)
Non-zero exit status: 25
Parse errors: Bad plan. You planned 14 tests but ran 8.
Files=1, Tests=8, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.08 cusr 0.01 csys = 0.11 CPU)
Result: FAIL
make[2]: *** [check] Error 1
make[2]: Leaving directory `/home/postgres/pgsql/src/bin/initdb'
make[1]: *** [check-initdb-recurse] Error 2
make[1]: Leaving directory `/home/postgres/pgsql/src/bin'
make: *** [check-world-src/bin-recurse] Error 2

The buildfarm looks pretty unhappy too, though I've not checked to see if
it's exactly the same symptom everywhere.

Or in more details:
Undefined subroutine &TestLib::run called at
/Users/mpaquier/git/postgres/src/bin/initdb/../../../src/test/perl/TestLib.pm
line 146.

BTW, not the fault of this patch in particular, but this example points
up the complaint I've had right along about how opaque TAP test failures
are. How did you dig down to see that error message? Is it even possible
to diagnose such a failure from what the buildfarm logs?

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

On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

BTW, not the fault of this patch in particular, but this example points
up the complaint I've had right along about how opaque TAP test failures
are. How did you dig down to see that error message?

Well, it showed up on my terminal...

Is it even possible to diagnose such a failure from what the buildfarm logs?

Yes. If you look at TestLib.pm, stderr/stdout redirection is done in
an INIT block, not BEGIN block, and INIT gets executed *after* the
code is compiled. FWIW, I recall arguing in favor of adding this
redirection logic in BEGIN so as we could get compilation errors
directly in the log files... The reason why it is done this way is
that it has been argued as well that we should not change the FS in
the BEGIN block, but in the INIT block when TestLib.pm is loaded.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Michael Paquier <michael.paquier@gmail.com> writes:

On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

BTW, not the fault of this patch in particular, but this example points
up the complaint I've had right along about how opaque TAP test failures
are. How did you dig down to see that error message?

Well, it showed up on my terminal...

Not on mine, as per the extract I showed. Probably a Perl version
difference, but I don't think we can exactly write off RHEL6 as an
uninteresting obsolete distribution. (The Perl here is 5.10.1.)

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

On Thu, Dec 3, 2015 at 12:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Michael Paquier <michael.paquier@gmail.com> writes:

On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

BTW, not the fault of this patch in particular, but this example points
up the complaint I've had right along about how opaque TAP test failures
are. How did you dig down to see that error message?

Well, it showed up on my terminal...

Not on mine, as per the extract I showed. Probably a Perl version
difference, but I don't think we can exactly write off RHEL6 as an
uninteresting obsolete distribution. (The Perl here is 5.10.1.)

Possible. On OSX 10.8:
$ perl --version

This is perl 5, version 16, subversion 2 (v5.16.2) built for
darwin-thread-multi-2level
(with 3 registered patches, see perl -V for more detail
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane wrote:

Michael Paquier <michael.paquier@gmail.com> writes:

On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

BTW, not the fault of this patch in particular, but this example points
up the complaint I've had right along about how opaque TAP test failures
are. How did you dig down to see that error message?

Well, it showed up on my terminal...

Not on mine, as per the extract I showed. Probably a Perl version
difference, but I don't think we can exactly write off RHEL6 as an
uninteresting obsolete distribution. (The Perl here is 5.10.1.)

Hmm, maybe a selinux policy or something like that is preventing some
system call from working, and this causes a Perl call to fail which we
may be failing to report; for instance we have
open(ORIG_STDOUT, ">&STDOUT");
in TestLib.pm's INIT block, without an "or die" which would let us know
that it failed.

--
�lvaro Herrera 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

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Tom Lane wrote:

Michael Paquier <michael.paquier@gmail.com> writes:

Well, it showed up on my terminal...

Not on mine, as per the extract I showed. Probably a Perl version
difference, but I don't think we can exactly write off RHEL6 as an
uninteresting obsolete distribution. (The Perl here is 5.10.1.)

Hmm, maybe a selinux policy or something like that is preventing some
system call from working,

Good thought, but overcomplicated. After some quality time with strace,
I find that the
Undefined subroutine &TestLib::run called at /home/postgres/pgsql/src/bin/initdb
/../../../src/test/perl/TestLib.pm line 146.
error message does indeed appear, but it's printed only into
src/bin/initdb/tmp_check/log/regress_log_001_initdb

It appears that the reason this happens is that the child perl process
(of the two that are active in this area of the trace) decides at one
point along the line to redirect its own stdout and stderr into that
file, disconnecting them from the pipes leading to the parent process.
So when that process prints "Undefined subroutine" to its stderr, that
is where it goes.

I suppose that the redirection is a result of this bit in TestLib.pm:

# Hijack STDOUT and STDERR to the log file
open(ORIG_STDOUT, ">&STDOUT");
open(ORIG_STDERR, ">&STDERR");
open(STDOUT, ">&TESTLOG");
open(STDERR, ">&TESTLOG");

so the question from my end is not so much why it doesn't work for me
as how it could possibly work for you. Could the newer Perl version
be detecting the undefined-subroutine error before it executes the
file's INIT stanza, rather than after? Or maybe the "tie" stuff
happening just below this acts differently in more modern Perls?

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