On 9 April 2010 18:21, Greg Smith <greg@xxxxxxxxxxxxxxx> wrote: > Ivan Voras wrote: >> >> I'd like to ask about the asynchronous nature of upcoming replication >> implementation in 9.0 - what guarantees does it give with regards to >> delays and latency? E.g. do COMMITs "finish" and return to the caller >> before or after the data is sent to the slave? (being asynchronous, they >> probably don't wait for the other side's confirmation, right?). >> > > Exactly--synchronous replication, the only way to enforce that data is on > the slave before completing the COMMIT, was postponed from this release. It > should make it into 9.1 as an option, but it will always be expensive to > turn on. > > What is in 9.0 is eventual consistency. If your slave is keeping up with > traffic being sent by the master, it should receive each incremental commit > shortly after it's made. In practice, slaves should only lag some number of > seconds behind the master. But there are zero guarantees that will be the > case, or that latency will be bounded at all. Recommended practice is to > carefully monitor how much latency lag there is on the standby and trigger > alerts if it exceed your expectations. Ok, but I imagine there should be a difference between COMMITs returning before or after the actual data is sent over the network (though admittedly socket buffering could make it hard to distinguish). In addition to that, how about a compromise: COMMITs returning when the remote side ACKs acceptance but before it passes data to storage? Just thinking out lout. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
