Re: Timeout for asynchronous replication Re: Timeout and wait-forever in sync rep

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Timeout for asynchronous replication Re: Timeout and wait-forever in sync rep
Date: 2010-12-06 14:54:15
Message-ID: 4CFCF917.2070809@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06.12.2010 08:51, Fujii Masao wrote:
> On Mon, Dec 6, 2010 at 3:42 PM, Fujii Masao<masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Fri, Oct 15, 2010 at 9:41 PM, Fujii Masao<masao(dot)fujii(at)gmail(dot)com> wrote:
>>> The timeout doesn't oppose to 'wait-forever'. Even if you choose 'wait
>>> -forever' (i.e., you set allow_standalone_master to false), the master
>>> should detect the standby crash as soon as possible by using the
>>> timeout. For example, imagine that max_wal_senders is set to one and
>>> the master cannot detect the standby crash because of absence of the
>>> timeout. In this case, even if you start new standby, it will not be
>>> able to connect to the master since there is no free walsender slot.
>>> As the result, the master actually waits forever.
>>
>> This occurred to me that the timeout would be required even for
>> asynchronous streaming replication. So, how about implementing the
>> replication timeout feature before synchronous replication itself?
>
> Here is the patch. This is one of features required for synchronous
> replication, so I added this into current CF as a part of synchronous
> replication.

Hmm, that's actually a quite different timeout than what's required for
synchronous replication. In synchronous replication, you need to get an
acknowledgment within a timeout. This patch only puts a timeout on how
long we wait to have enough room in the TCP send buffer. That doesn't
seem all that useful.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc Balmer 2010-12-06 14:55:38 Re: Suggesting a libpq addition
Previous Message Robert Haas 2010-12-06 14:53:31 Re: WIP patch for parallel pg_dump