Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794)

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794)
Дата
в 19:54:40
Msg-id
21165.1462391672@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
modifying WaitEventSets (was: Performance degradation in commit ac1d794) Robert Haas <robertmhaas@gmail.com>
Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794) Andres Freund <andres@anarazel.de>
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) Tom Lane <tgl@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) Tom Lane <tgl@sss.pgh.pa.us>
Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794) Andres Freund <andres@anarazel.de>
Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794) Robert Haas <robertmhaas@gmail.com>
Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794) Andres Freund <andres@anarazel.de>
Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794) Merlin Moncure <mmoncure@gmail.com>
Robert Haas  writes:
> On Wed, May 4, 2016 at 3:35 PM, Tom Lane  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 по дате отправления
От: Tom Lane
Дата:
От: Joshua D. Drake
Дата:
FAQ