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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Send new protocol keepalive messages to standby servers.
Date: 2012-05-29 19:34:20
Message-ID: CA+U5nML=dphswfmUNY1ix9H+DSg5-9Q4vx7TCV6BiUM6WU9E3g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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.

Adding functions is the work of a few hours, but not worth starting
that if you intend to block it.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian 2012-05-30 00:55:25 Re: pgsql: Eliminate some more O(N^2) behaviors in pg_dump/pg_restore.
Previous Message Heikki Linnakangas 2012-05-29 19:28:58 pgsql: Fix integer overflow bug in GiST buffering build calculations.

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-05-29 19:40:43 Re: pg_upgrade libraries check
Previous Message Heikki Linnakangas 2012-05-29 19:13:40 GiST buffering build, bug in levelStep calculation