On Mon, Sep 11, 2017 at 6:27 PM, Fabien COELHO <coe...@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