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.1807171704530.22281@lancre
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
Hello Heikki,

> [...] Let's keep it that way. I think the only change we need to make in 
> the logic is to check at the end, if *any* progress reports at all have 
> been printed, and print one if not.

Ok, this simplifies the condition.

> And do that only when the -P option is smaller than the -T option, I 
> suppose.

Yep, why not.

> Oh. I'm a bit surprised we don't support decimals, i.e. -P 0.5. Actually, it 
> seems to be acceptd, but it's truncated down to the nearest integer.

Indeed, "atoi" does not detect errors, and it is true of the many uses in 
pgbench: clients, threads, scale, duration, fillfactor...

> That's not very nice :-(. But it's a separate issue.

Yep. For human consumption, seconds seem okay.

>> 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.
>
> That sounds reasonable. It's a bit silly to wait when there's nothing to do, 
> but it's also weird if the test exits before the specified time is up. Seems 
> less surprising to always sleep.

I did that in the attached version: no more environment variable hack, and 
no execution shortcut even if there is nothing to do.

I also had to reproduce the progress logic to keep on printing report of 
(no) progress in this tailing phase.

I'm not very happy because it is a change of behavior. I suggest that I 
could add a special "--strict-time-compliance" option to do this only when 
required... and it would only be required by tap tests.

-- 
Fabien.
Вложения

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

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: [HACKERS] PATCH: multivariate histograms and MCV lists
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Fix some error handling for read() and errno