Re: Synchronous Log Shipping Replication

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Markus Wanner <markus(at)bluegap(dot)ch>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Synchronous Log Shipping Replication
Date: 2008-09-10 08:39:41
Message-ID: 48C787CD.9090304@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> Saying "I want to wait for a synchronous commit and I am willing to wait
> for ever to ensure it" leads to long hangs in some cases.

Sure. That's the fundamental problem with synchronous replication.
That's why many people choose asynchronous replication instead. Clearly
at some point you'll want to give up and continue without the slave, or
kill the master and fail over to the slave. I'm wondering how that's
different than the lag between master and server in asynchronous
replication from the client's point of view.

> I was suggesting that some users may wish to wait up to time X before
> responding to the commit. The WALSender may keep retrying long after
> that point, but that doesn't mean all current users need to do that
> also. The user would need to say whether the response to the timeout was
> an error, or just accept and get on with it.

I'm not sure I understand that paragraph. Who's the user? Do we need to
expose some new information to the client so that it can do something?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2008-09-10 08:48:20 Re: WIP patch: Collation support
Previous Message Hannu Krosing 2008-09-10 08:36:26 Re: Keeping creation time of objects