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).
> 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.
Regards
Markus Wanner