Re: buildfarm animals and 'snapshot too old'

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

In response to

Responses

Browse pgsql-hackers by date

  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