pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feed From: Tom Lane <tgl@sss.pgh.pa.us>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Andrew Dunstan <andrew.dunstan@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 13:22:39 -0400
Message-ID: <15361.1489771359@sss.pgh.pa.us> (raw )
In-Reply-To: <dd5d7eae-cc0a-88a1-193f-88893b6963da@2ndquadrant.com >
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 >
<dd5d7eae-cc0a-88a1-193f-88893b6963da@2ndquadrant.com >
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Petr Jelinek <petr.jelinek@2ndquadrant.com> writes:
> On 17/03/17 17:28, Tom Lane wrote:
>> 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.
> Thanks, now that I look at it again I think we might need to do cycle
> with the occurred_events and returned_events and not return on first
> find since theoretically there can be multiple sockets if this gets
> called directly and not via WaitLatchOrSocket(). I don't have mental
> power to finish it up right now though, sorry for that.
I think WaitEventSet is only required to identify at least one reason
for ending the wait; it is not required to identify all of them.
(Even if it tried to do so, the information could be out of date by
the time it returns.) So I'm not particularly fussed about that,
even if we had code that waited on write-ready for multiple sockets
which I don't believe we do.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
view thread (22+ messages) latest in thread
Message-ID: <15361.1489771359@sss.pgh.pa.us>
Permalink: ../15361.1489771359@sss.pgh.pa.us/
Also on: postgresql.org/message-id/15361.1489771359@sss.pgh.pa.us
copy link · copy postgr.es
reply 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: tgl@sss.pgh.pa.us, petr.jelinek@2ndquadrant.com, andrew.dunstan@2ndquadrant.com, peter.eisentraut@2ndquadrant.com, pgsql-hackers@postgresql.org
Subject: Re: [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver
In-Reply-To: <15361.1489771359@sss.pgh.pa.us>
* 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