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

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).

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