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

On Thu, Mar 10, 2016 at 8:35 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Thu, Mar 10, 2016 at 12:35 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> I looked into COMMIT PREPARED replay feedback and realised that it
>> doesn't need any special handling beyond what is already in
>> xact_redo_commit. However, I see now that I *do* need to do something
>> when replaying PREPARE TRANSACTION, as you said. Not for causal reads
>> though -- it doesn't care about an operation with no visible effect --
>> but for synchronous_commit = remote_apply. I am thinking about how to
>> fix that.
>
> Ok, here is a new version with the following changes:
>
> 1. If you PREPARE TRANSACTION with synchronous_commit = remote_apply,
> it just waits for remote WAL flush. When you eventually
> COMMIT/ROLLBACK PREPARED, it waits for remote apply. Also, the
> XACT_COMPLETION_SYNC_APPLY_FEEDBACK bit is now set in appropriate
> abort records, and then handled in recovery, just as for commits, so
> that ROLLBACK and ROLLBACK PREPARED return at the right time in
> remote_apply.
>
> 2. I fixed a recently introduced stupid bug that caused causal reads
> to be broken when sync rep wasn't also configured (I had lost a change
> to stop SyncRepReleaseWaiters from leaving early, when I split up the
> patch... oops).
>
> 3. I switched the pg_stat_replication.replay_lag accounting from
> milliseconds to microseconds. The measured lag with fast machines on
> local networks can sometimes be sub-millisecond or very low numbers of
> milliseconds, so it's interesting to see more detail (depending on the
> primary's clock resolution).

The last patches I posted don't apply today due to changes in master,
so here's a freshly merged patch series.

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