Re: pgbench logging broken by time logic changes
От | Fabien COELHO |
---|---|
Тема | Re: pgbench logging broken by time logic changes |
Дата | |
Msg-id | alpine.DEB.2.22.394.2106231125540.1117163@pseudo обсуждение исходный текст |
Ответ на | Re: pgbench logging broken by time logic changes (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pgbench logging broken by time logic changes
|
Список | pgsql-hackers |
Bonjour Michaël, > Could it be possible to document the intention of the test and its > coverage then? With the current patch, one has to guess what's the > intention behind this case. Ok, see attached. >>> +check_pgbench_logs($bdir, '001_pgbench_log_1', $nthreads, 1, 3, >>> + qr{^\d{10,} \d{1,2} \d+ \d+ \d+ \d+ \d+ \d+ \d+ \d+ \d+$}); > > Hm.. Could it be possible to tighten a bit the regex used here then? > I was playing with it and it is not really picky in terms of patterns > allowed or rejected. > The follow-up checks for check_pgbench_logs() could be a bit more > restrictive as well, but my regex-fu is bad. Given the probabilistic nature of a --rate run and the variability of hosts which may run the tests, it is hard to be more specific that \d+ for actual performance data. The run may try 0 or 50 transaction within a second (both with pretty low probabilities), so the test mostly checks the format and some basic sanity on the output and logs. >>> I would say to give up on the first test, and keep the second. >> >> You mean remove the time check and keep the log check. I'd like to keep a >> time check, or at least have it in comment so that I can enable it simply. > > I'd rather avoid tests that tend to fail on slow machines. There is a > flotilla in the buildfarm. Commented out in attached v9. -- Fabien.
Вложения
В списке pgsql-hackers по дате отправления: