Re: pgbench - minor fix for meta command only scripts

Jeff Janes <jeff.janes@gmail.com>

From: Jeff Janes <jeff.janes@gmail.com>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2017-09-29T16:39:43Z
Lists: pgsql-hackers
On Mon, Sep 11, 2017 at 6:27 PM, Fabien COELHO <coelho@cri.ensmp.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

Commits

  1. Fix busy-wait in pgbench, with --rate.

  2. Refactor script execution state machine in pgbench.