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

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)
Date: 2018-07-18 14:44:10
Message-ID: 2db34429-06db-e049-feaa-2d8c9483559b@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-07-18 14:56:31 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message Jesper Pedersen 2018-07-18 14:35:56 Re: partition tree inspection functions