From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 20:05:04 |
Message-ID: | CA+TgmobFk9e-VPuJoeE4-LWE7Y1mYqxveO0FW6orGkqwOSnDgg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 4, 2016 at 3:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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?
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-05-04 20:07:01 | Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794) |
Previous Message | Robert Haas | 2016-05-04 20:03:31 | Re: release management team statement on patch reverts |