Andrew Dunstan <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
