On 03/22/2011 09:33 PM, Robert Haas wrote: > We might have a version of synchronous replication that works this way > some day, but it's not the version were shipping with 9.1. The slave > acknowledges the WAL records when they hit the disk (i.e. fsync) not > when they are applied; WAL apply can lag arbitrarily. The point is to > guarantee clients that the WAL is on disk somewhere and that it will > be replayed in the event of a failover. Despite the fact that this > doesn't work as you're describing, it's a useful feature in its own > right.
In that sense, our approach may be more synchronous than most others, because after the ACK is sent from the slave, the slave still needs to apply the transaction data from WAL before it gets visible, while the master needs to wait for the ACK to arrive at its side, before making it visible there. Ideally, these two latencies (disk seek and network induced) are just about equal. But of course, there's no such guarantee. So whenever one of the two is off by an order of magnitude or two (by use case or due to a temporary overload), either the master or the slave may lag behind the other machine. What pleases me is that the guarantee from the slave is somewhat similar to Postgres-R's: with its ACK, the receiving node doesn't guarantee the transaction *is* applied locally, it just guarantees that it *will* be able to do so sometime in the future. Kind of a mind twister, though... Regards Markus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
