Hi,
On 2016-05-04 15:54:32 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, May 4, 2016 at 3:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> 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.
Yea, I think that's the case. I just ran the query for a longer period,
and there's not been any report since 2014 of an !windows animal without
poll support.
> > 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.
>
> I'm not either, but ...
I'm not worried about slightly degraded capabilities there either, more
about the (lack of) ability to test that reasonably.
> > 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.
>
> ... the evidence available suggests that the select() code path has
> probably received zero buildfarm testing. Do we really want to ship
> a fourth implementation that we can't even vouch for?
I mean I added code to make it easier to test the select path in 9.6,
but yea, outside of my machines running the latest linux kernel there
is, that code path appears to have had barely any testing over the last
few years.
Andres