Re: Streaming replication and non-blocking I/O

On Tue, Dec 8, 2009 at 11:23 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> The first question is: do we really need to be prepared for that? The
> XLogRecPtr acknowledgment messages the client sends are very small, and
> if the client is mindful about not sending them too often - perhaps max
> 1 ack per 1 received XLOG message - the receive buffer in the backend
> should never fill up in practice.

It's OK to drop that feature.

> 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).

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center