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 20:29:36
Message-ID: alpine.DEB.2.21.1807181616130.26741@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>>> 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.
>
> Can you elaborate? I don't think that's how it works. In threadRun(), we have
> this:

The state path I want to avoid is, without getting out of doCustom, is:

CHOOSE_SCRIPT:
-> START_THROTTLE (i.e. under -R)
START_THROTTLE:
update txn_schedule, which happen to be after end_time,
i.e. the transaction is scheduled after the expected end of the run.
but if the condition is removed, then proceed directly to
-> THROTTLE
THROTTLE:
if now has passed txn_schedule (we are late), no return, proceed
directly to -> START_TX
START_TX:
-> START_COMMAND
START_COMMAND: executed... & "return" on SQL, but it is too late
for stopping the tx now, it has started.

Maybe I missed something, but it looks to me that we can get in the
situation where a transaction scheduled beyond the end of run is started
anyway if it happens that it was a little late.

> [... threadRun ...]
> As soon as the -T timer is exceeded, the above code will close all
> connections that are in CSTATE_THROTTLE state.

So threadRun() would not have the opportunity to stop the scheduled
transaction, even if beyond the end of run, because it would not have got
out of doCustom, in the case I outlined above.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Finzel 2018-07-18 20:30:43 Re: Background worker/idle sessions and caching
Previous Message Alvaro Herrera 2018-07-18 20:26:32 Re: psql's \d versus included-index-column feature