Skip site navigation (1) Skip section navigation (2)

Re: Streaming replication and SSL

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication and SSL
Date: 2010-02-03 18:31:54
Message-ID: 9837222c1002031031r12e0de44v2fcc5214192012af@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Feb 3, 2010 at 08:23, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Fujii Masao wrote:
>> 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.
>
> 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/

In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-02-03 18:33:42
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Previous:From: Tom LaneDate: 2010-02-03 18:28:02
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group