From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: buildfarm animals and 'snapshot too old' |
Date: | 2014-05-15 20:07:57 |
Message-ID: | 53751E9D.9020406@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/15/2014 03:57 PM, Tomas Vondra wrote:
>> 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.
> *
> * If used with CLOBBER_FREED_MEMORY, CLOBBER_CACHE_ALWAYS provides a
> * 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.
> */
>
Yes, I've seen that. Frankly, a test that takes something like 500 hours
is a bit crazy.
If we really want to run this in the buildfarm we should probably try to
create a massively cut down test schedule for use in this case.
Incidentally, should the CLOBBER_CACHE_ALWAYS machines also be defining
CLOBBER_FREED_MEMORY?
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2014-05-15 20:13:49 | Re: Proposal for CSN based snapshots |
Previous Message | Andres Freund | 2014-05-15 20:06:32 | Re: Proposal for CSN based snapshots |