On 06.12.2010 08:51, Fujii Masao wrote:
On Mon, Dec 6, 2010 at 3:42 PM, Fujii Masao<masao.fu...@gmail.com> wrote:
On Fri, Oct 15, 2010 at 9:41 PM, Fujii Masao<masao.fu...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
