Re: Sync Rep: First Thoughts on Code

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sync Rep: First Thoughts on Code
Date: 2008-12-04 11:41:04
Message-ID: 4937C1D0.1010807@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> On Thu, 2008-12-04 at 17:57 +0900, Fujii Masao wrote:
>
>> On Wed, Dec 3, 2008 at 3:38 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>>>>> Do we need to worry about periodic
>>>>>> renegotiation of keys in be-secure.c?
>>>>> What is "keys" you mean?
>>>> See the notes in that file for explanation.
>>> Thanks! I would check it.
>> The key is used only when we use SSL for the connection of
>> replication. As far as I examined, secure_write() renegotiates
>> the key if needed. Since walsender calls secure_write() when
>> sending the WAL to the standby, the key is renegotiated
>> periodically. So, I think that we don't need to worry about the
>> obsolescence of the key.
>
> Understood. Is the periodic renegotiation of keys something that would
> interfere with the performance or robustness of replication? Is the
> delay likely to effect sync rep? I'm just checking we've thought about
> it.

It will certainly add an extra piece of delay. But if you are worried
about performance for it, you are likely not running SSL. Plus, if you
don't renegotiate the key, you gamble with security.

If it does have a negative effect on the robustness of the replication,
we should just recommend against using it - or refuse to use - not
disable renegotiation.

/Magnus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-12-04 11:57:45 Re: Sync Rep: First Thoughts on Code
Previous Message Gregory Stark 2008-12-04 11:21:10 Re: In-place upgrade: catalog side