On Wed, Mar 23, 2016 at 11:32 PM, Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers