Re: Timeout for asynchronous replication Re: Timeout and wait-forever in sync rep
От | Heikki Linnakangas |
---|---|
Тема | Re: Timeout for asynchronous replication Re: Timeout and wait-forever in sync rep |
Дата | |
Msg-id | 4CFCF917.2070809@enterprisedb.com обсуждение исходный текст |
Ответ на | Timeout for asynchronous replication Re: Timeout and wait-forever in sync rep (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Timeout for asynchronous replication Re: Timeout and
wait-forever in sync rep
Re: Timeout for asynchronous replication Re: Timeout and wait-forever in sync rep |
Список | pgsql-hackers |
On 06.12.2010 08:51, Fujii Masao wrote: > On Mon, Dec 6, 2010 at 3:42 PM, Fujii Masao<masao.fujii@gmail.com> wrote: >> On Fri, Oct 15, 2010 at 9:41 PM, Fujii Masao<masao.fujii@gmail.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
В списке pgsql-hackers по дате отправления: