Fujii Masao wrote:
> On Wed, Jan 13, 2010 at 7:27 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> the frontend always puts the
>> connection to non-blocking mode, while the backend uses blocking mode.
>
> Really? By default (i.e., without the expressly setting by using
> PQsetnonblocking()), the connection is set to blocking mode even
> in frontend. Am I missing something?
That's right. The underlying socket is always put to non-blocking mode
in libpq. PQsetnonblocking() only affects whether libpq commands wait
and retry if the output buffer is full.
>> At least with SSL, I think it's possible for pq_wait() to return false
>> positives, if the SSL layer decides to renegotiate the connection
>> causing data to flow in the other direction in the underlying TCP
>> connection. A false positive would lead cause walsender to block
>> indefinitely on the pq_getbyte() call.
>
> Sorry. I could not understand that issue scenario. Could you explain
> it in more detail?
1. Walsender calls pq_wait() which calls select(), waiting for timeout,
or data to become available for reading in the underlying socket.
2. Client issues an SSL renegotiation by sending a message to the server
3. Server receives the message, and select() returns indicating that
data has arrived
4. Walsender calls HandleEndOfRep() which calls pq_getbyte().
pq_readbyte() calls SSL_read(), which receives the renegotiation message
and handles it. No application data has arrived, however, so SSL_read()
blocks for some to arrive. It never does.
I don't understand enough of SSL to know if renegotiation can actually
happen like that, but the man page of SSL_read() suggests so. But a
similar thing can happen if an SSL record is broken into two TCP
packets. select() returns immediately as the first packet arrives, but
SSL_read() will block until the 2nd packet arrives.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
