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
-
Fix busy-wait in pgbench, with --rate.
- babf18579455 10.0 landed
- 396ef1561878 11.0 landed
-
Refactor script execution state machine in pgbench.
- 12788ae49e19 10.0 cited