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

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
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 19:56:02
Message-ID: alpine.DEB.2.21.1807181505080.26741@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2018-07-18 20:04:54 Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)
Previous Message Tom Lane 2018-07-18 19:55:35 psql's \d versus included-index-column feature