Portability issues in TAP tests

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Portability issues in TAP tests
Date: 2014-07-17 19:31:19
Message-ID: 10107.1405625479@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

My Salesforce colleagues have been complaining that the TAP tests added
in 9.4 don't work terribly well for them. I've been poking at this,
and I believe this is a reasonably complete list of the problems:

1. "make [install]check-world" tries to run the TAP tests even when
"prove" was not found by configure. I regard this as a stop-ship issue
for 9.4; "prove" is not part of a basic Perl installation, and even if
it were, we don't require Perl to build from a tarball.

2. Most of the tests fail in "make check" mode, unless you already did
"make install", because of failures to load libpq.so. The right fix for
this seems to be to modify LD_LIBRARY_PATH and friends to include the temp
install's libdir, comparably to what pg_regress.c does (lines 903ff in
HEAD). Unfortunately we can't just borrow that code since there is no
C wrapper involved in the TAP tests. (Maybe there should be?) This again
seems like a stop-ship issue.

3. Many of the tests depend on Test::More's "subtest" feature, which
unfortunately is of rather recent vintage (2009 or so). It's not present
for example in RHEL6's version of Test::More, and presumably not in any
older distros either. I'm not sure if we should consider it acceptable
to depend on this feature: it doesn't seem exactly critical, and if we
continue to use it, there is approximately 0 chance that we'll ever be
able to enable the TAP tests on many of the existing buildfarm members.
In any case, as long as we depend on it, there had better be some cleaner
response to older versions of Test::More than just blowing up.

4. IPC::Run isn't installed by default on RHEL, and probably not on other
distros either. If there's a reasonably painless way to remove this
dependency, it'd improve the portability of the tests. This is lower
priority than the previous items, for sure.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-07-17 19:38:06 Re: [v9.5] Custom Plan API
Previous Message Peter Geoghegan 2014-07-17 19:05:00 Re: BUFFER_LOCK_EXCLUSIVE is used in ginbuildempty().