On Tue, Jan 3, 2017 at 3:43 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > Here is a new version of my "causal reads" patch (see the earlier > thread from the 9.6 development cycle), which provides a way to > avoid stale reads when load balancing with streaming replication.
Thanks for working on this. It will let us do something a lot of people have been asking for. > Long term, I think it would be pretty cool if we could develop a set > of features that give you distributed sequential consistency on top of > streaming replication. Something like (this | causality-tokens) + > SERIALIZABLE-DEFERRABLE-on-standbys + > distributed-dirty-read-prevention. Is it necessary that causal writes wait for replication before making the transaction visible on the master? I'm asking because the per tx variable wait time between logging commit record and making transaction visible makes it really hard to provide matching visibility order on master and standby. In CSN based snapshot discussions we came to the conclusion that to make standby visibility order match master while still allowing for async transactions to become visible before they are durable we need to make the commit sequence a vector clock and transmit extra visibility ordering information to standby's. Having one more level of delay between wal logging of commit and making it visible would make the problem even worse. One other thing that might be an issue for some users is that this patch only ensures that clients observe forwards progress of database state after a writing transaction. With two consecutive read only transactions that go to different servers a client could still observe database state going backwards. It seems that fixing that would require either keeping some per client state or a global agreement on what snapshots are safe to provide, both of which you tried to avoid for this feature. Regards, Ants Aasma -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers