Re: buildfarm animals and 'snapshot too old'

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: buildfarm animals and 'snapshot too old'
Date: 2014-05-20 13:42:15
Message-ID: 24480.1400593335@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2014-05-20 13:59:19 Re: Buffer manager scalability and correlated reference period
Previous Message Andrew Dunstan 2014-05-20 13:35:59 Re: buildfarm animals and 'snapshot too old'