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.1807180826260.11604@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,

>> 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.
>
> On second thoughts, there's one problem with this approach of always waiting 
> until -T is up. What if all the threads died because of errors? For example:

Good corner-case catch! This behavior is indeed silly.

> I don't think you want to wait in that situation. I think we should wait at 
> the end only if there some threads still alive, with nothing to do only 
> because of --rate.

Yep. The attached version does only the tailing stuff under -R and not all 
threads were stopped on errors, with comments to tell about the why.

I'm still wondering about a specific option to explicitely require this 
behavioral change.

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

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: PG 10: could not generate random cancel key
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] WAL logging problem in 9.4.3?