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

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Thom Brown <thom(at)linux(dot)com>, 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-03-10 07:35:05
Message-ID: CAEepm=2O-uopbJhS788MzPVD3zobjbP4Rts=ftp-a9k=pY4-cQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
0001-remote-apply-v3.patch application/octet-stream 18.4 KB
0002-replay-lag-v3.patch application/octet-stream 25.5 KB
0003-refactor-syncrep-exit-v3.patch application/octet-stream 4.6 KB
0004-causal-reads-v3.patch application/octet-stream 74.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-03-10 07:35:43 Re: pg_rewind just doesn't fsync *anything*?
Previous Message Mithun Cy 2016-03-10 07:34:45 Re: POC: Cache data in GetSnapshotData()