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 2db34429-06db-e049-feaa-2d8c9483559b@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 18/07/18 16:01, Fabien COELHO wrote:
>> 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.

Hmm. How about we just remove this special case from doCustom():

>            case CSTATE_START_THROTTLE:
 > ...
> 
>                 /*
>                  * stop client if next transaction is beyond pgbench end of
>                  * execution
>                  */
>                 if (duration > 0 && st->txn_scheduled > end_time)
>                 {
>                     st->state = CSTATE_FINISHED;
>                     break;
>                 }

That way, we let the client go into CSTATE_THROTTLE state, even though 
we know that the timer will run out before we reach txn_scheduled. Then 
it will work the way we want, right? One small difference is that then 
the clients will keep the connections open longer, until the timer 
expires, but I think that's reasonable. Less surprising than the current 
behavior, even.

- Heikki


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

Предыдущее
От: Jesper Pedersen
Дата:
Сообщение: Re: partition tree inspection functions
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions