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 по дате отправления: