Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794)
От | Tom Lane |
---|---|
Тема | Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794) |
Дата | |
Msg-id | 21165.1462391672@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: modifying WaitEventSets (was: Performance degradation
in commit ac1d794)
Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794) |
Список | pgsql-hackers |
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. > 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 ... > 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? regards, tom lane
В списке pgsql-hackers по дате отправления: