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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
