Обсуждение: Streaming replication and SSL
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
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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/