Streaming replication and SSL
От | Fujii Masao |
---|---|
Тема | Streaming replication and SSL |
Дата | |
Msg-id | 3f0b79eb1002022038t89fb8e8ue00f649bebb8377f@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Streaming replication and SSL
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: