On 08/07/2015 02:03 PM, Andres Freund wrote:
>>> but you will have to use a 9.5 pgbench to see it, especially with higher
>>> client counts.
>
> Hm, you were using -P X, is that right?
>
>> This bisects down to 1bc90f7a7b7441a88e2c6d4a0e9b6f9c1499ad30 - "Remove
>> thread-emulation support from pgbench."
>
> And the apparent reason seems to be that too much code has been removed
> in that commit:
>
> @@ -3650,11 +3631,7 @@ threadRun(void *arg)
> }
>
> /* also wake up to print the next progress report on time */
> - if (progress && min_usec > 0
> -#if !defined(PTHREAD_FORK_EMULATION)
> - && thread->tid == 0
> -#endif /* !PTHREAD_FORK_EMULATION */
> - )
> + if (progress && min_usec > 0)
> {
> /* get current time if needed */
> if (now_usec == 0)
> @@ -3710,7 +3687,7 @@ threadRun(void *arg)
>
>
> This causes all threads but thread 0 (i.e. the primary process) to busy
> loop around select: min_usec will be set to 0 once the first progress
> report interval has been reached:
> if (now_usec >= next_report)
> min_usec = 0;
> else if ((next_report - now_usec) < min_usec)
> min_usec = next_report - now_usec;
>
> but since we never actually print the progress interval in any thread
> but the the main process that's always true from then on:
>
> /* progress report by thread 0 for all threads */
> if (progress && thread->tid == 0)
> {
> ...
> /*
> * Ensure that the next report is in the future, in case
> * pgbench/postgres got stuck somewhere.
> */
> do
> {
> next_report += (int64) progress *1000000;
> } while (now >= next_report);
>
> Hrmpf.
>
Confirmed.
Running w/o -P x and the problem goes away.
Thanks !
Best regards, Jesper
