Re: buildfarm animals and 'snapshot too old'
От | Andrew Dunstan |
---|---|
Тема | Re: buildfarm animals and 'snapshot too old' |
Дата | |
Msg-id | 53751E9D.9020406@dunslane.net обсуждение исходный текст |
Ответ на | Re: buildfarm animals and 'snapshot too old' ("Tomas Vondra" <tv@fuzzy.cz>) |
Ответы |
Re: buildfarm animals and 'snapshot too old'
Re: buildfarm animals and 'snapshot too old' |
Список | 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
В списке pgsql-hackers по дате отправления: