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