Re: [HACKERS] pgbench - minor fix for meta command only scripts
| От | Jeff Janes |
|---|---|
| Тема | Re: [HACKERS] pgbench - minor fix for meta command only scripts |
| Дата | |
| Msg-id | CAMkU=1xF8AtjG1BAb5Xrxu-KorW=s1WGsauhMmaQ_JPuPD0UbQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] pgbench - minor fix for meta command only scripts (Fabien COELHO <coelho@cri.ensmp.fr>) |
| Ответы |
Re: [HACKERS] pgbench - minor fix for meta command only scripts
|
| Список | 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
В списке pgsql-hackers по дате отправления: