On Thu, Apr 19, 2012 at 2:47 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Apr 19, 2012, at 5:05 AM, Magnus Hagander <mag...@hagander.net> wrote: >> I admit to not having followed the discussion around the new mode for >> synchronous_commit very closely, so my apologies if this has been >> discussed and dismiseed - I blame failing to find it int he archives >> ;) >> >> My understanding from looking at the docs is that >> synchronous_commit=remote_write will always imply a *local* commit as >> well. >> >> Is there any way to set the system up to do a write to the remote, >> ensure it's in memory of the remote (remote_write mode, not full sync >> to disk), but *not* necessarily to the local disk? Meaning we're ok to >> release the transaction when the data is in memory both locally and >> remotely but not wait for I/O? > > If we crash, the slave can end up ahead of the master, and then it's > hopelessly corrupted... > > Maybe we could engineer around this, but it hasn't been done yet.
The work around would be for the master to refuse to automatically restart after a crash, insisting on a fail-over instead (or a manual forcing of recovery)? Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers