Fujii Masao wrote:
> On Thu, Jan 14, 2010 at 7:04 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> 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.
>
> What is the trigger of the renegotiation? The backend initiates it
> when the amount of data sent exceeds the RENEGOTIATION_LIMIT (which
> is defined in src/backend/libpq/be-secure.c). OTOH, I cannot find
> the code that the libpq explicitly does that. So I wonder if client
> (i.e., walreceiver in this case) really sends the SSL renegotiation
> message. Correct me if I'm wrong.
I have no idea. I thought the SSL library can do so whenever it feels
like it, but I'm not sure.
The other problem scenario was that the server receive only the first
half of an SSL packet. That doesn't produce any data available to read
with SSL_read(), so SSL_read() will block, but it does wake up a select().
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com