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

On Sun, Feb 28, 2016 at 2:20 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 9:39 AM, Thom Brown <thom@linux.com> wrote:
>> On 21 February 2016 at 23:18, Thomas Munro
>> <thomas.munro@enterprisedb.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.

Thanks for looking at the patch!  Here is a new version with the
following changes:

1.  Some draft user documentation has been added, as requested.

2.  The new synchronous commit level (separate from the causal reads
feature, but implemented for completeness) is now called
"remote_apply" instead of "apply", as suggested by Thom Brown.

3.  There is a draft README.causal_reads file which provides some
developer notes about state transitions, leases and clock skew.

4.  The 'joining' state management has been improved (it's now based
on xlog positions rather than time; see the README and comments for
details).

5.  The ps title is now restored after it is modified during causal
reads-related waiting.

6.  I assigned an errcode (40P02) for causal reads failures (useful
for clients/middleware/libraries that might want to handle this error
automatically), as suggested by a couple of people off-list.

--
Thomas Munro
http://www.enterprisedb.com