On Tue, Sep 7, 2010 at 9:45 AM, Markus Wanner <mar...@bluegap.ch> wrote: > On 09/07/2010 02:16 PM, Robert Haas wrote: >> >> Right, definitely. The trouble is that if they happen concurrently, >> and there's a crash, you have to be prepared for the possibility that >> either one of the two has completed and the other is not. > > Understood. > >> In >> practice, this means that the master and standby need to compare notes >> on the ending WAL location and whichever one is further advanced needs >> to stream the intervening records to the other. > > Not necessarily, no. Remember that the client didn't get a commit > confirmation. So reverting might also be a correct solution (i.e. not > violating the durability constraint).
In theory, that's true, but if we do that, then there's an even bigger problem: the slave might have replayed WAL ahead of the master location; therefore the slave is now corrupt and a new base backup must be taken. >> This would be an >> awesome feature, but it's hard, so for a first version, it makes sense >> to commit on the master first and then on the standby after the master >> is known done. > > The obvious downside of that is that latency adds up, instead of just being > the max of the two operations. And that for normal operation. While at best > it saves an un-confirmed transaction in the failure case. > > It might be harder to implement, yes. Yeah, I hope we'll get there eventually. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
