Thread: Streaming replication and SSL

Streaming replication and SSL

From
Fujii Masao
Date:
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.

Regards,

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


Re: Streaming replication and SSL

From
Heikki Linnakangas
Date:
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


Re: Streaming replication and SSL

From
Magnus Hagander
Date:
On Wed, Feb 3, 2010 at 08:23, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> 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.

It can only do it when we call the library. Which means at send or
receive :-) But AFAIK either end (sender or receiver) can initiate it.


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

Yeah.

It can be re-woken, because SSL_read() will eventually be calling back
into our own functions, but that would require a second signal before
it wakes up of course..


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/