On 15 Květen 2014, 19:46, Andrew Dunstan wrote:
> 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.

I don't know. According to this comment from cache/inval.c, it's expected
to be way slower (~100x) compared to CLOBBER_CACHE_ALWAYS.

 * Test code to force cache flushes anytime a flush could happen.
 * fairly thorough test that the system contains no cache-flush hazards.
 * However, it also makes the system unbelievably slow --- the regression
 * tests take about 100 times longer than normal.
 * If you're a glutton for punishment, try CLOBBER_CACHE_RECURSIVELY. This
 * slows things by at least a factor of 10000, so I wouldn't suggest
 * trying to run the entire regression tests that way.It's useful to try
 * a few simple tests, to make sure that cache reload isn't subject to
 * internal cache-flush hazards, but after you've done a few thousand
 * recursive reloads it's unlikely you'll learn more.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to