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  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Accessing base table relational names via RelOptInfo
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Postgres with pthread