I wrote:
> 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.
To check into my assumptions here, I did a bit of testing to find out
what ppoll can really do in terms of timeout accuracy. As best I can
tell, its resolution is on the order of 100 usec on both fairly new
Linux kernels (4.17.19 on Fedora 28) and fairly old ones (2.6.32 on
RHEL6). So there's not really that much daylight between what you can
do with ppoll() and with poll()'s millisecond resolution. select(2)
seems to have about the same effective timeout resolution.
Interestingly, select(2)'s timeout resolution is noticeably better than
that, around 10 usec, on recent macOS. Didn't try other platforms.
Also, I'd misunderstood the portability angle. Unlike pselect(),
ppoll() is *not* in POSIX. It started as a Linux-ism, although
I see it's appeared recently in FreeBSD. That somewhat assuages
my fear of broken implementations on specific platforms, but it
also means that it's going to be far from universally available.
So the question here really boils down to whether you think that a
large set of pgbench connections is interesting on non-Linux platforms.
There's a case to be made that it isn't, perhaps, but I'm not exactly
sold.
On the other hand, while we could certainly make a poll-based code path
within this patch, I'm not quite sure what we'd do with it. My results
for macOS indicate that using poll rather than select would create a
tradeoff: in return for possibly allowing more clients, there would be
a definite loss in timeout precision. I don't think that limiting
\sleep commands to ms precision would be so awful, but it's easier
to believe that loss of precision in the transaction dispatch rate for
"--rate" tests could be a problem for some people. So we might have
to expose the choice of which call to use to users, which seems like
a mess.
So maybe what we've got here --- make it better on Linux, with no
change elsewhere --- is about as good as we can hope for.
Also, I notice that the kevent syscall available on macOS and some
BSDen uses a struct-timespec timeout parameter, ie, theoretical nsec
resolution same as ppoll. So there's a case to be made that where
we should go for those platforms is to build a kevent-based code
path not a poll-based one. It'd be unreasonable to insist on this
patch providing that, though.
Anyway, bottom line: my objection on Wednesday was mainly based on
the assumption that we might have to contend with broken ppoll on
some platforms, which now appears to be fallacious. So, objection
withdrawn.
regards, tom lane