On Wed, May 4, 2016 at 3:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> Given that poll() has been introduced in SRV3 - which IIRC was below our
>>> usual baseline - and windows is not an issue for latch, I think it'd
>>> be ok to rely on it.
>
>> I think it's entirely reasonable to say that "if you want high performance
>> you should have poll(3)". Failing to build without it would be a harder
>> sell, probably.
>
> Hmm ... wait, I take that back. poll() is required by SUS v2, which has
> been our minimum baseline spec for a long time (even my pet dinosaur HPUX
> has it). As long as we have an answer for Windows, it's hard to argue
> we can't require poll() elsewhere.
I don't think we'd necessarily need to completely de-support people
who still depend on select(). We'd just need to say, well,
WL_SOCKET_ERROR *may* report exceptional events on the socket, or it
may not, depending on how modern your platform is. In the use cases I
foresee, that would occasionally result in less-timely detection of
FDW connection loss, but nothing worse. I'm not prepared to get very
excited about that.
But if we are confident that everything supports poll() and it's
always better than select(), another, possibly superior option is to
remove support for select() and see if anything breaks. If not, then
we only need to support three platform-specific implementations
instead of four, which I would find it difficult to complain about.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
