Re: Streaming replication and non-blocking I/O

Fujii Masao wrote:
> On Tue, Dec 8, 2009 at 11:23 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> If that's deemed not good enough, we could modify just internal_flush()
>> so that it uses secure_poll to wait for the possibility to either read
>> or write, instead of blocking for just write. Whenever there's incoming
>> data, read them into PqRecvBuffer for later processing, which keeps the
>> OS input buffer from filling up. If PqRecvBuffer fills up, it can be
>> extended, or we can start dropping old XLogRecPtr messages from it.
>
> Extending PqRecvBuffer seems better because XLogRecPtr message
> has some types (i.e., we cannot just drop old message without parsing
> all messages in the buffer).

True. Another idea I had was to introduce a callback that backend libpq
can call when the buffer fills. Walsender would set the callback to
ProcessStreamMsgs().

But if everyone is happy with just relying on the OS buffer to not fill
up, let's just drop it.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com