Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd) - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)
Date
Msg-id alpine.DEB.2.21.1807181616130.26741@lancre
Whole thread Raw
In response to Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)  (Heikki Linnakangas <hlinnaka@iki.fi>)
List 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.


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: psql's \d versus included-index-column feature
Next
From: Jeremy Finzel
Date:
Subject: Re: Background worker/idle sessions and caching