Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver
Date
Msg-id 15361.1489771359@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API inlibpqwalreceiver  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] [PATCH] Move all am-related reloption code intosrc/backend/access/[am-name] and get rid of relopt_kind for custom AM
Next
From: Jeff Janes
Date:
Subject: [HACKERS] pageinspect and hash indexes