Re: buildfarm animals and 'snapshot too old' - Mailing list pgsql-hackers

From Tom Lane
Subject Re: buildfarm animals and 'snapshot too old'
Date
Msg-id 24480.1400593335@sss.pgh.pa.us
Whole thread Raw
In response to Re: buildfarm animals and 'snapshot too old'  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: buildfarm animals and 'snapshot too old'  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
Re: buildfarm animals and 'snapshot too old'  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 05/20/2014 07:09 AM, Tom Lane wrote:
>> Robert's got a point here.  In my usage, the annoying thing is not animals
>> that take a long time to report in; it's the ones that lie about the
>> snapshot time (which is how you get "512abc4 in the middle of a bunch of
>> ef9ab5f's").  That is an issue of incorrect system clock, not of how long
>> it takes to do the run.  I wonder if the buildfarm script could be taught
>> to get the timestamp from an NTP server somewhere?  Or at least
>> sanity-check the system clock reading by comparing it to the newest commit
>> timestamp in the git repo.

> Regarding clock skew, I think we can do better then what you suggest. 
> The web transaction code in the client adds its own timestamp just 
> before running the web transaction. It would be quite reasonable to 
> reject reports from machines with skewed clocks based on this value. I'm 
> not sure what a reasonable skew might be. Somewhere in the range of 5 to 
> 15 minutes seems reasonable.

Rather than reject, why not take the result and adjust the claimed start
timestamp by the difference between the web transaction timestamp and the
buildfarm server's time?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: buildfarm animals and 'snapshot too old'
Next
From: Amit Kapila
Date:
Subject: Re: Buffer manager scalability and correlated reference period