From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver
Date: Fri, 17 Mar 2017 14:51:54 -0400
Message-ID: <927edd39-ed04-ea57-a98c-638eb0365431@2ndQuadrant.com> (raw)
In-Reply-To: <13398.1489768097@sss.pgh.pa.us>
References: <E1cjo1g-0000mr-ST@gemulon.postgresql.org>
<19403.1488586564@sss.pgh.pa.us>
<34d98fbf-9195-04d2-b85a-634d6952ffdf@2ndquadrant.com>
<19815.1488600693@sss.pgh.pa.us>
<4144256b-dc4f-892c-a720-71f6e7b9ac87@2ndquadrant.com>
<dcef4616-21af-5ec0-4113-d409e5ddbf86@2ndquadrant.com>
<3ffe98f7-d2ed-65c6-51f3-4d97ffd6e312@2ndquadrant.com>
<e31d81e2-392a-dca0-a700-e28b583bd2d3@2ndQuadrant.com>
<34591606-976a-bbee-8eda-778c1e1fc52f@2ndQuadrant.com>
<10458.1489763266@sss.pgh.pa.us>
<5b6a6d6d-fb45-0afb-2e95-5600063c3dbd@2ndquadrant.com>
<13398.1489768097@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 03/17/2017 12:28 PM, Tom Lane wrote:
> Petr Jelinek <petr.jelinek@2ndquadrant.com> writes:
>> Now the documentation for WSAEventSelect says "The FD_WRITE network
>> event is handled slightly differently. An FD_WRITE network event is
>> recorded when a socket is first connected with a call to the connect,
>> ConnectEx, WSAConnect, WSAConnectByList, or WSAConnectByName function or
>> when a socket is accepted with accept, AcceptEx, or WSAAccept function
>> and then after a send fails with WSAEWOULDBLOCK and buffer space becomes
>> available. Therefore, an application can assume that sends are possible
>> starting from the first FD_WRITE network event setting and lasting until
>> a send returns WSAEWOULDBLOCK. After such a failure the application will
>> find out that sends are again possible when an FD_WRITE network event is
>> recorded and the associated event object is set."
>> But while PQconnectPoll does connect() before setting connection status
>> to CONNECTION_STARTED and returns PGRES_POLLING_WRITING so the FD_WRITE
>> eventually happens, it does not do any writes in the code block that
>> switches to CONNECTION_MADE and PGRES_POLLING_WRITING. That means
>> FD_WRITE event is never recorded as per quoted documentation.
> Ah-hah! Great detective work.
>
>> Then what remains is why it works in libpq. If you look at
>> pgwin32_select which is eventually called by libpq code, it actually
>> handles the situation by trying empty WSASend on any socket that is
>> supposed to wait for FD_WRITE and only calling the
>> WaitForMultipleObjectsEx when WSASend failed with WSAEWOULDBLOCK, when
>> the WSASend succeeds it immediately returns ok.
>> So I did something similar in attached for WaitEventSetWaitBlock() and
>> it indeed solves the issue my windows test machine. Now the
>> coding/placement probably isn't the best (and there are no comments),
>> but maybe somebody will find proper place for this now that we know the
>> cause.
> Yeah, I'm afraid we had better do something more or less like this.
> It's interesting to speculate about whether WaitEventSet could keep
> additional state that would avoid the need for a dummy send() every
> time, but that seems like material for new development not a bug fix.
>
> In any case, a quick review of the code suggests that there are no
> performance-critical places where we wait for WL_SOCKET_WRITEABLE
> unless we've already detected that we have to wait for the network;
> so the dummy send() isn't going to do anything except consume a
> few more CPU cycles before we get to the point of blocking. It may
> not be worth worrying about.
>
> I'll add some comments and push this. Does everyone agree that
> this had better get back-patched, too?
>
>
Confirmed that this fixes the problem on jacana.
+1 for backpatching.
Does that mean we could remove the special logic in pgstat.c?
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: andrew.dunstan@2ndquadrant.com, tgl@sss.pgh.pa.us, petr.jelinek@2ndquadrant.com, peter.eisentraut@2ndquadrant.com, pgsql-hackers@postgresql.org
Subject: Re: [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver
In-Reply-To: <927edd39-ed04-ea57-a98c-638eb0365431@2ndQuadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox