On Tue, Sep 7, 2010 at 4:01 AM, Markus Wanner <mar...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
