From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 20:15:34 |
Message-ID: | 537BB7E6.8070403@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/20/2014 03:59 PM, Gavin Flower wrote:
> On 21/05/14 01:42, Tom Lane wrote:
>> 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?
>>
>>
>>
> I think, that if possible, any such adjustment should be noted along
> with the original time, so that:
>
> 1. the timing issue can be remedied
> 2. it is possible to link the output to any messages in the machines
> log etc.
>
I don't see how that's going to help anyone. Major clock skew is a sign
of client misconfiguration. And where would we note this adjustment, and
who would do anything about it?
We seem to be engaging in a sort of PoohBearism* here. More information
is not always better.
cheers
andrew
*
Rabbit: Would you like *condensed milk*, or *honey* on your bread?
Winnie the Pooh: Both. But never mind the bread, please.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-05-20 20:17:29 | Re: jsonb failed assertions |
Previous Message | Gavin Flower | 2014-05-20 19:59:21 | Re: buildfarm animals and 'snapshot too old' |