On Tue, May 10, 2011 at 12:45 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, May 10, 2011 at 5:14 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
>> On 10 May 2011 09:45, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> wrote:
>>
>>> I think we need to refactor the function into something like:
>>>
>>> #define WL_LATCH_SET 1
>>> #define WL_SOCKET_READABLE 2
>>> #define WL_SOCKET_WRITEABLE 4
>>> #define WL_TIMEOUT 8
>>> #define WL_POSTMASTER_DEATH 16
>>
>> While I agree with the need to not box ourselves into a corner on the
>> latch interface by making sweeping assumptions, isn't the fact that a
>> socket became readable or writable strictly an implementation detail?
>
> The thing about the socket being readable/writeable is needed for
> walsender. It needs to notice when its connection to walreceiver is
> writeable (so it can send more WAL) or readable (so it can receive a
> reply message).
I've got a feeling that things will go easier if we have a separate
connection for the feedback channel.
Yes, two connections, one in either direction.
That would make everything simple, nice one way connections. It would
also mean we could stream at higher data rates.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
