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.1807181505080.26741@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)
|
Список | pgsql-hackers |
Hello Heikki, >> 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: >> // ... >> 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. Hmmm... in this instance, and if this test is removed, ISTM that it can start the transaction, re-establishing a connection under --connect, and the transaction will run to its end even if it is beyond the expected end of run. So removing this test does not seem desirable. -- Fabien.
В списке pgsql-hackers по дате отправления: