Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd) |
Дата | |
Msg-id | alpine.DEB.2.21.1807130000070.27883@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd) (Fabien COELHO <coelho@cri.ensmp.fr>) |
Список | pgsql-hackers |
>>> Indeed… but then throttling would not be tested:-) The point of the test >>> is to exercise all time-related options, including throttling with a >>> reasonable small value. >> >> Ok. I don't think that's really worthwhile. If we add some code that only >> runs in testing, then we're not really testing the real thing. I wouldn't >> trust the test to tell much. Let's just leave out that magic environment >> variable thing, and try to get the rest of the patch finished. > > If you remove the environment, then some checks need to be removed, because > the 2 second run may be randomly shorten when there is nothing to do. If not, > the test will fail underterminiscally, which is not acceptable. Hence the > hack. I agree that it is not beautiful. > > The more reasonable alternative could be to always last 2 seconds under -T 2, > even if the execution can be shorten because there is nothing to do at all, > i.e. remove the environment-based condition but keep the sleep. Yet another option would be to replace the env variable by an option, eg "--strict-time", that would be used probaly only by the TAP test, but would be an available feature. -- Fabien.
В списке pgsql-hackers по дате отправления: