On 05/15/2014 12:43 PM, Tomas Vondra wrote:
Hi all,today I got a few of errors like these (this one is from last week, though): Status Line: 493 snapshot too old: Wed May 7 04:36:57 2014 GMT Content: snapshot to old: Wed May 7 04:36:57 2014 GMT on the new buildfarm animals. I believe it was my mistake (incorrectly configured local git mirror), but it got me thinking about how this will behave with the animals running CLOBBER_CACHE_RECURSIVELY. If I understand the Perl code correctly, it does this: (1) update the repository (2) run the tests (3) check that the snapshot is not older than 24 hours (pgstatus.pl:188) (4) fail if older Now, imagine that the test runs for days/weeks. This pretty much means it's wasted, because the results will be thrown away anyway, no?
The 24 hours runs from the time of the latest commit on the branch in question, not the current time, but basically yes.
We've never had machines with runs that long. The longest in recent times has been friarbird, which runs CLOBBER_CACHE_ALWAYS and takes around 4.5 hours. But we have had misconfigured machines reporting unbelievable snapshot times. I'll take a look and see if we can tighten up the sanity check. It's worth noting that one thing friarbird does is skip the install-check stage - it's almost certainly not going to have terribly much interesting to tell us from that, given it has already run a plain "make check".
How long does a CLOBBER_CACHE_RECURSIVELY run take? days or weeks seems kinda nuts.
cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
