Re: [HACKERS] snapbuild woes - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] snapbuild woes
Date
Msg-id 12f78f6b-3a18-2456-62f0-e2821213af1d@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] snapbuild woes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 5/1/17 13:02, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2017-05-01 12:32:07 -0400, Tom Lane wrote:
>>> But quite aside from the question of whether we can afford the cycles,
>>> it seems like the wrong approach.  IMO the buildfarm is mainly for
>>> verifying portability, not for trying to prove that race-like
>>> conditions don't exist.  In most situations we're going out of our way
>>> to ensure reproduceability of tests we add to the buildfarm sequence;
>>> but it seems like this is looking for irreproducible results.
> 
>> Yea, I wondered about that upthread as well.  But the tests are quite
>> useful nonetheless.  Wonder about adding them simply as a separate
>> target.
> 
> I have no objection to adding more tests as a non-default target.

Well, the problem with nondefault targets is that they are hard to find
if you don't know them, and then they will rot.

Sure, we need a way to distinguish different classes of tests, but lets
think about the bigger scheme, too.  Ideas welcome.

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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table