On 05/20/2014 03:59 PM, Gavin Flower wrote:
On 21/05/14 01:42, Tom Lane wrote:
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?
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
