From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Proposal: "Causal reads" mode for load balancing reads without stale data |
Date: | 2016-02-27 22:54:36 |
Message-ID: | CAA-aLv6c2LER+--TXdJuqDDsv2t7uyWFGV3O4WxOuP2suNVCBg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 27 February 2016 at 13:20, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
> On Mon, Feb 22, 2016 at 9:39 AM, Thom Brown <thom(at)linux(dot)com> wrote:
>> On 21 February 2016 at 23:18, Thomas Munro
>> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> The replay_lag is particularly cool. Didn't think it was possible to
>> glean this information on the primary, but the timings are correct in
>> my tests.
>>
>> +1 for this patch. Looks like this solves the problem that
>> semi-synchronous replication tries to solve, although arguably in a
>> more sensible way.
>
> Yeah, having extra logic at application layer to check if a certain
> LSN position has been applied or not is doable, but if we can avoid it
> that's a clear plus.
>
> This patch has no documentation. I will try to figure out by myself
> how the new parameters interact with the rest of the syncrep code
> while looking at it but if we want to move on to get something
> committable for 9.6 it would be good to get some documentation soon.
Could we rename "apply" to "remote_apply"? It seems more consistent
with "remote_write", and matches its own enum entry too.
Thom
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2016-02-28 00:05:47 | Re: postgres_fdw vs. force_parallel_mode on ppc |
Previous Message | Kevin Grittner | 2016-02-27 22:38:24 | Re: The plan for FDW-based sharding |