Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)
От | Heikki Linnakangas |
---|---|
Тема | Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd) |
Дата | |
Msg-id | 6b405304-012a-2529-3207-651338d10d03@iki.fi обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd) (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)
|
Список | pgsql-hackers |
On 12/07/18 19:00, Fabien COELHO wrote: >>> How pgbenchs prints a progress if none were printed, or if the last >>> progress was over 0.5 seconds ago, so as to have kind of a catchup in the >>> end. >> >> I don't understand the 0.5 second rule. For the tests, we only need to ensure >> that at least one progress report is printed, right? > > I'm not so sure;-) I do not want to trust the threadRun loop in case of > heavy load or whatever issue a run may encounter, so this approach ensures > that structurally there is always one output even of the whole loop went > very wrong. I still don't understand. For the testing, we just need to make sure that at least one progress report is always printed, if -P is used. Right? So where does the 0.5 second rule come in? Can't we just do "if (no progress reports were printed) { print progress report; }" at the end? > It also adds a small feature which is that there is always a final > progress when the run is completed, which can be useful when computing > progress statistics, otherwise some transactions could not be reported in > any progress at all. Any transactions in the last 0.5 seconds might still not get reported in any progress reports. >>> when there is nothing to do. This ensures that the -T 2 tap test runs for >>> at least 2 seconds, whatever. If the host is overload it might be more, >>> but it cannot be less unless something was wrong. >> >> If you want to write a test that checks that a two-second test takes at least >> two seconds, can't you just not use throttling in that test? > > 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. - Heikki
В списке pgsql-hackers по дате отправления: