On Tue, Sep 7, 2010 at 4:01 AM, Markus Wanner <markus@bluegap.ch> wrote:
> In any case, a server failure in between the commit request of the client
> and the commit confirmation for the client results in a client that can't
> tell if its transaction committed or not.
>
> So why do we care what to do first internally? Ideally, these two tasks
> should happen concurrently, IMO.
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. 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. 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company