Re: [HACKERS] Failure in commit_ts tap tests - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] Failure in commit_ts tap tests
Date
Msg-id 20170123142339.GW18360@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] Failure in commit_ts tap tests  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom, Andrew,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> > On 01/20/2017 01:22 PM, Tom Lane wrote:
> >> It looks like at least part of the answer is that the buildfarm isn't
> >> running this test.  AFAICS, it runs "make installcheck" not
> >> "make check" in src/test/modules.  I don't know whether any of the
> >> critters would have duplicated the failure, but they weren't trying.
>
> > Is there a reason why these tests aren't run under installcheck? If
> > there is a justification I can look at it, or we should decide on one
> > canonical mode of running the tests and stick to that.
>
> Well, for at least some of them, "make check" is necessary because they
> need to change postmaster parameters or load special shared libraries.

Yes, having to fight with the buildfarm to have something like pgaudit
properly tested by the build animals is extremely frustrating.

The TAP tests do seem to allow that sort of thing these days, though I
haven't peronsally tried to create any which load special shared
libraries yet.  I also haven't looked to see how many animals actually
run them, though hopefully we can encourage more people to do so as we
improve our testing with them.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Failure in commit_ts tap tests
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Odd plan shown in src/backend/optimizer/README