Re: pgbench - minor fix for meta command only scripts

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench - minor fix for meta command only scripts
Date: 2017-09-29 16:39:43
Message-ID: CAMkU=1xF8AtjG1BAb5Xrxu-KorW=s1WGsauhMmaQ_JPuPD0UbQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 11, 2017 at 6:27 PM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:

>
> Hello Jeff,
>
> Shouldn't we use pg_usleep to ensure portability? it is defined for
>> front-end code. But it returns void, so the error check will have to be
>> changed.
>>
>
> Attached v3 with pg_usleep called instead.
>
> I didn't see the problem before the commit I originally indicated , so I
>> don't think it has to be back-patched to before v10.
>>
>
> Hmmm.... you've got a point, although I'm not sure how it could work
> without sleeping explicitely. Maybe the path was calling select with an
> empty wait list plus timeout, and select is kind enough to just sleep on an
> empty list, or some other miracle.

Not really a miracle, calling select with an empty list of file handles is
a standard way to sleep on Unix-like platforms. (Indeed, that is how
pg_usleep is implemented on non-Windows platforms, see
"src/port/pgsleep.c"). The problem is that it is reportedly not portable
to Windows. But I tested pgbench.exe for 9.6.5-1 from EDB installer, and I
don't see excessive CPU usage for a throttled run, and it throttles to
about the correct speed. So maybe the non-portability is more rumor than
reality. So I don't know if this needs backpatching or not. But it should
be fixed for v10, as there it becomes a demonstrably live issue.

> ISTM clearer to explicitly sleep in that case.

Yes.

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-09-29 16:43:13 Re: Shaky coding for vacuuming partitioned relations
Previous Message Bossart, Nathan 2017-09-29 16:36:25 Re: Shaky coding for vacuuming partitioned relations