On 11/12/15 1:11 PM, Thomas Munro wrote:
It's true that a pooling system/middleware could spy on your sessions and insert causality token handling imposing a global ordering of visibility for you, so that naive users don't have to deal with them. Whenever it sees a COMMIT result (assuming they are taught to return LSNs), it could update a highest-LSN-seen variable, and transparently insert a wait for that LSN into every transaction that it sees beginning. But then you would have to push all your queries through a single point that can see everything across all Postgres servers, and maintain this global high LSN.
I think that depends on what you're doing. Frequently you don't care about anyone elses writes, just your own. In that case, there's no need for a shared connection pooler, you just have to come back to the same one.
There's also a 4th option: until a commit has made it out to some number of slaves, re-direct all reads from a session back to the master. That might sound horrible for master performance, but in reality I think it'd normally be fine. Generally, you only care about this when you're going to read data that you've just written, which means the data's still in shared buffers.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
