Re: Failure in commit_ts tap tests

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Failure in commit_ts tap tests
Date: 2017-01-23 14:23:39
Message-ID: 20170123142339.GW18360@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom, Andrew,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-01-23 14:39:10 Re: Odd plan shown in src/backend/optimizer/README
Previous Message Tom Lane 2017-01-23 14:22:28 Re: Failure in commit_ts tap tests