Streaming replication and SSL

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

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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/