RE: seems like a bug in pgbench -R

Hello Yoshikazu,

>> I could not reproduce this issue on head, but I confirm on 11.2.
>
> I could reproduce the stuck on 11.4.
>
>> Attached is a fix to apply on pg11.
>
> I confirm the stuck doesn't happen after applying your patch.

Ok, thanks for the feedback.

>> + /* under throttling we may have finished the last client above */
>> + if (remains == 0)
>> + break;
>
> If there are only CSTATE_WAIT_RESULT, CSTATE_SLEEP or CSTATE_THROTTLE clients,
> a thread needs to wait the results or sleep. In that logic, there are the case
> that a thread tried to wait the results when there are no clients wait the
> results, and this causes the issue. This is happened when there are only
> CSTATE_THROTLE clients and pgbench timeout is occured. Those clients will be
> finished and "remains" will be 0.
>
> I confirmed above codes prevent such a case.

Yep.

> I almost think this is ready for committer,

Almost great, then.

> but I have one question. Is it better adding any check like if(maxsock
> != -1) before the select?
>
> else /* no explicit delay, select without timeout */
> {
> nsocks = select(maxsock + 1, &input_mask, NULL, NULL, NULL);
> }

I think that it is not necessary because this case cannot happen: If some
clients are still running (remains > 0), they are either sleeping, in
which case there would be a timeout, or they are waiting for something
from the server, otherwise the script could be advanced further so there
would be something else to do for the thread.

We could check this by adding "Assert(maxsock != -1);" before this select,
but I would not do that for a released version.

--
Fabien.