From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Streaming replication and SSL |
Date: | 2010-02-03 04:38:03 |
Message-ID: | 3f0b79eb1002022038t89fb8e8ue00f649bebb8377f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 14, 2010 at 7:04 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-02-03 04:38:33 | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] |
Previous Message | Alex Hunsaker | 2010-02-03 04:30:31 | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] |