Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)

Heikki Linnakangas <hlinnaka@iki.fi>

From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2018-07-18T14:44:10Z
Lists: 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


Commits

  1. Refactor code to print pgbench progress reports.

  2. Fix pgbench TAP test to work in VPATH builds.