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

Re: Replication server timeout patch

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Replication server timeout patch
Date: 2011-03-31 02:46:54
Message-ID: AANLkTimB34ZC+XY-3EgazJuKgWy80XO17w2LfXNuLD5a@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Mar 30, 2011 at 10:54 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Mar 30, 2011 at 4:08 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Wed, Mar 30, 2011 at 5:03 PM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> On 30.03.2011 10:58, Fujii Masao wrote:
>>>>
>>>> On Wed, Mar 30, 2011 at 4:24 PM, Heikki Linnakangas
>>>> <heikki(dot)linnakangas(at)enterprisedb(dot)com>  wrote:
>>>> +        A value of zero means wait forever.  This parameter can only be
>>>> set in
>>>>
>>>> The first sentence sounds misleading. Even if you set the parameter to
>>>> zero,
>>>> replication connections can be terminated because of keepalive or socket
>>>> error.
>>>
>>> Hmm, should I change it back to "A value of zero disables the timeout" ? Any
>>> better suggestions?
>>
>> I like that. But I appreciate if anyone suggests the better.
>
> Maybe sticking the word "mechanism" in there would be a bit better.
> "A value of zero disables the timeout mechanism"?

I'm OK with that. Or, what about "A value of zero turns this off" which is
used in statement_timeout for the sake of consistency?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

pgsql-hackers by date

Next:From: Brendan JurdDate: 2011-03-31 03:39:25
Subject: Re: [HACKERS] Date conversion using day of week
Previous:From: Bruce MomjianDate: 2011-03-31 02:17:41
Subject: Re: Problem with pg_upgrade?

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