Re: [HACKERS] pgbench regression test failure

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] pgbench regression test failure
Дата
Msg-id 6751.1505239936@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] pgbench regression test failure  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: [HACKERS] pgbench regression test failure  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> By definition, parallelism induces non determinism. When I put 2 seconds, 
> the intention was that I would get a non empty trace with a "every second" 
> aggregation. I would rather take a longer test rather than allowing an 
> empty file: the point is to check that something is generated, but 
> avoiding a longer test is desirable. So I would suggest to stick to 
> between 1 and 3, and if it fails then maybe add one second...

That's a losing game.  You can't ever guarantee that N seconds is
enough for slow, heavily loaded machines, and cranking up N just
penalizes developers who are testing under normal circumstances.

I have a serious, serious dislike for tests that seem to work until
they're run on a heavily loaded machine.  So unless there is some
reason why pgbench is *guaranteed* to run at least one transaction
per thread, I'd rather the test not assume that.

I would not necessarily object to doing something in the code that
would guarantee that, though.
        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] pgbench regression test failure
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] domain type smashing is expensive