RE: seems like a bug in pgbench -R - Mailing list pgsql-hackers

From Fabien COELHO
Subject RE: seems like a bug in pgbench -R
Date
Msg-id alpine.DEB.2.21.1907241852360.28372@lancre
Whole thread Raw
In response to RE: seems like a bug in pgbench -R  ("Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>)
Responses RE: seems like a bug in pgbench -R
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Statistical aggregate functions are not working with PARTIALaggregation
Next
From: Fabien COELHO
Date:
Subject: Re: psql - add SHOW_ALL_RESULTS option