Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794)
От | Robert Haas |
---|---|
Тема | Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794) |
Дата | |
Msg-id | CA+TgmobFk9e-VPuJoeE4-LWE7Y1mYqxveO0FW6orGkqwOSnDgg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: modifying WaitEventSets (was: Performance degradation
in commit ac1d794)
|
Список | pgsql-hackers |
On Wed, May 4, 2016 at 3:54 PM, Tom Lane <tgl@sss.pgh.pa.us> 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. > >> 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? I'm more than happy to rip it out, either now or after the tree opens for 9.7 development. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: