On Wed, Sep 8, 2010 at 9:32 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Wed, Sep 8, 2010 at 10:07 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Sep 8, 2010 at 8:30 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >>>> And in any event, there is ALWAYS a window of >>>> time during which the client doesn't know the transaction has >>>> committed but other transactions can potentially see its effects. >>> >>> Yep. The problem here is that synchronous replication is likely to >>> make the window very big. >> >> So what? If the correctness of your application depends on the >> *amount of time* this window lasts, it's already broken. It seems >> like you're arguing that we should artificially increase lock >> contention to guard against possible race conditions in user >> applications. That doesn't make any sense to me, so one of us is >> confused. > > Yep ;) On second thought, the problem here is that the effects of > the transaction marked as committed but still waiting for replication > can disappear after failover.
Ah! I think that's right. So the scenario we're trying to guard against something like this. A customer makes a withdrawal of money from an ATM; their bank balance is debited. The transaction tries to commit. After the transaction becomes visible to other backends but before WAL is reaches the standby, another transaction begins and reads the customer's balance. Naturally, they get the new, lower balance. Crash, master dead. Failover. If another transcation begins and reads the customer's balance again, it's back to the old value. So we have a phantom transaction: it appeared as committed and then vanished again. So that means we have to make sure that none of the effects of a transaction can be seen until WAL is fsync'd on the master AND the slave has acked. -- 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