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

On Wed, Mar 23, 2016 at 11:32 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Well, I wouldn't go that far. It seems pretty clear that remote_apply
> by itself is useful - I can't imagine anybody seriously arguing the
> contrary, whatever they think of this implementation. My view,
> though, is that by itself that's pretty limiting: you can only have
> one standby, and if that standby falls over then you lose
> availability. Causal reads fixes both of those problems - admittedly
> that requires some knowledge in the application or the pooler, but
> it's no worse than SSI in that regard. Still, half a loaf is better
> than none, and I imagine even just getting remote_apply would make a
> few people quite happy.

OK, let's do so then, even if causal reads don't get into 9.6 users
could get advantage of remote_apply on multiple nodes if the N-sync
patch gets in.

Just looking at 0001.

- <literal>remote_write</>, <literal>local</>, and <literal>off</>.
+ <literal>remote_write</>, <literal>remote_apply</>,
<literal>local</>, and <literal>off</>.
The default, and safe, setting
I imagine that a run of pgindent would be welcome for such large lines.

+#define XactCompletionSyncApplyFeedback(xinfo) \
+ (!!(xinfo & XACT_COMPLETION_SYNC_APPLY_FEEDBACK))
That's not directly something this patch should take care of, but the
notation "!!" has better be avoided (see stdbool thread with VS2015).

- SyncRepWaitForLSN(gxact->prepare_end_lsn);
+ SyncRepWaitForLSN(gxact->prepare_end_lsn, false);
Isn't it important to ensure that a PREPARE LSN is applied as well on
the standby with remote_apply? Say if an application prepares a
transaction, it would commit locally but its LSN may not be applied on
the standby with this patch. That would be a surprising behavior for
the user.

(not commenting on the latch and SIGUSR2 handling, you are still
working on it per your last update).
--
Michael