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-14 03:50:57 |
Message-ID: | CAEepm=2x4iF=ZuZdVmFtTs83gZzYpyjFd_X4ZFrjQiz4hxQqiQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
0001-remote-apply-v4.patch | application/octet-stream | 18.4 KB |
0002-replay-lag-v4.patch | application/octet-stream | 25.5 KB |
0003-refactor-syncrep-exit-v4.patch | application/octet-stream | 4.6 KB |
0004-causal-reads-v4.patch | application/octet-stream | 74.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kouhei Kaigai | 2016-03-14 04:04:46 | Re: WIP: Upper planner pathification |
Previous Message | James Sewell | 2016-03-14 03:39:04 | Re: Parallel Aggregate |