On 3 January 2017 at 01:43, 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[1]), which provides a way to > avoid stale reads when load balancing with streaming replication. I'm very happy that you are addressing this topic. I noticed you didn't put in links my earlier doubts about this specific scheme, though I can see doubts from myself and Heikki at least in the URLs. I maintain those doubts as to whether this is the right way forwards. This patch presumes we will load balance writes to a master and reads to a pool of standbys. How will we achieve that? 1. We decorate the application with additional info to indicate routing/write concerns. 2. We get middleware to do routing for us, e.g. pgpool style read/write routing The explicit premise of the patch is that neither of the above options are practical, so I'm unclear how this makes sense. Is there some use case that you have in mind that has not been fully described? If so, lets get it on the table. What I think we need is a joined up plan for load balancing, so that we can understand how it will work. i.e. explain the whole use case and how the solution works. I'm especially uncomfortable with any approaches that treat all sessions as one pool. For me, a server should support multiple pools. Causality seems to be a property of a particular set of pools. e.g. PoolS1 supports causal reads against writes to PoolM1 but not PoolM2, yet PoolS2 does not provide causal reads against PoolM1 orPoolM2. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers