"Rady, Doug" <radyd...@amazon.com> writes: > This patch enables building pgbench to use ppoll() instead of select() > to allow for more than (FD_SETSIZE - 10) connections. As implemented, > when using ppoll(), the only connection limitation is system resources.
So ... why exactly is this patch insisting on ppoll() rather than just plain poll()? AFAICS, all you're doing with that is being able to specify the timeout in microsec not millisec, which does not really justify taking much of a hit in portability, to my mind. > “… ppoll() is to poll() as pselect() is to select(). Since the > existing code uses select(), why not convert to poll() rather than > ppoll()?” A moment's glance at our git history will remind you that we attempted to start using pselect() last year, and the attempt crashed and burned: Author: Tom Lane <t...@sss.pgh.pa.us> Branch: master Release: REL_10_BR [64925603c] 2017-04-24 18:29:03 -0400 Revert "Use pselect(2) not select(2), if available, to wait in postmaster's loop." This reverts commit 81069a9efc5a374dd39874a161f456f0fb3afba4. Buildfarm results suggest that some platforms have versions of pselect(2) that are not merely non-atomic, but flat out non-functional. Revert the use-pselect patch to confirm this diagnosis (and exclude the no-SA_RESTART patch as the source of trouble). If it's so, we should probably look into blacklisting specific platforms that have broken pselect. Discussion: https://postgr.es/m/9696.1493072...@sss.pgh.pa.us Now, it might be that ppoll doesn't suffer from as many portability problems as pselect, but I don't see a good reason to assume that. So I'd rather see if we can't convert this to use poll(), and thereby ensure that it works basically everywhere. regards, tom lane