Re: Proposal: "Causal reads" mode for load balancing reads without stale data

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