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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Васильев Дмитрий <d(dot)vasilyev(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794)
Date: 2016-05-04 19:54:32
Message-ID: 21165.1462391672@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, May 4, 2016 at 3:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2016-05-04 20:00:25 Re: release management team statement on patch reverts
Previous Message Tom Lane 2016-05-04 19:51:07 Re: release management team statement on patch reverts