Re: Re: [COMMITTERS] pgsql: Send new protocol keepalive messages to standby servers.

On Wed, May 30, 2012 at 4:34 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 24 May 2012 21:11, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Thu, May 24, 2012 at 2:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>> On Wed, May 23, 2012 at 2:28 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>>>> Is there plan to implement such external functions before 9.2 release?
>>>>> If not, keepalive protocol seems to be almost useless because there is
>>>>> no use of it for a user and the increase in the number of packets might
>>>>> increase the replication performance overhead slightly. No?
>>>
>>>> Good point.  IMHO, this shouldn't really have been committed like
>>>> this, but since it was, we had better fix it, either by reverting the
>>>> change or forcing an initdb to expose the functionality.
>>>
>>> I see no reason to rip the code out if we have plans to make use of it
>>> in the near future.  I am also not for going back into development mode
>>> on 9.2, which is what adding new functions now would amount to.  What's
>>> wrong with leaving well enough alone?  It's not like there is no
>>> unfinished work anywhere else in Postgres ...
>>
>> So, extra TCP overhead for no user-visible benefit doesn't bother you?
>
> Other changes occurred such that WAL messages don't get sent at all in
> many cases on an idle server. The keep alive replaces that, so is of
> value in itself.
>
> The new functions would have made most sense if file based keepalives
> had been approved. But that didn't make it in and hence incomplete.

Even if we don't have file based keepalives, the new function enables us
to calculate the network latency, so it seems worth exposing the function.

OTOH, I wonder whether we really need to send keepalive messages
periodically to calculate a network latency. ISTM we don't unless a network
latency varies from situation to situation so frequently and we'd like to
monitor that in almost real time.

Regards,

--
Fujii Masao