Re: pgsql: When VACUUM or ANALYZE skips a concurrently dropped table, log i
От | Tom Lane |
---|---|
Тема | Re: pgsql: When VACUUM or ANALYZE skips a concurrently dropped table, log i |
Дата | |
Msg-id | 11630.1512595870@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: When VACUUM or ANALYZE skips a concurrently dropped table,log i (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pgsql: When VACUUM or ANALYZE skips a concurrently dropped table,log i
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Dec 6, 2017 at 12:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> What appears to be happening is that a database-wide ANALYZE takes more >> than a minute under CLOBBER_CACHE_ALWAYS, causing isolationtester.c's >> hardwired one-minute timeout to trigger. > Is it really our policy that no isolation test can take more than a > minute on the slowest buildfarm critter? Well, I think it's a minute per query not per whole test script. But in any case, if it's taking a longer time than any other isolation test on the CLOBBER_CACHE_ALWAYS critters, then it's also taking a proportionately longer time than any other test on every other platform, and is therefore costing every developer precious time today and indefinitely far into the future. I continue to say that this test ain't worth it. It's possible that we could compromise on dropping the steps that test whole-database VACUUM/ANALYZE; the incremental gain from testing those scenarios is certainly even less worth its cost than the basic cases. regards, tom lane
В списке pgsql-hackers по дате отправления: