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
