On Sun, Oct 4, 2015 at 11:47 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > (Seems like you forgot to push the Reply-all button) > > On Sun, Oct 4, 2015 at 7:01 PM, Madovsky wrote: >> On 10/3/2015 3:30 PM, Michael Paquier wrote: >>> and no reason is given to justify *why* this would be needed in your case >> reason for a choice can be often an issue for other :D >> >> I thought that postgresql 9.4 user could change on the fly with >> synchronous_commit from local to on for ex >> which hotstandby would become in sync and which in async to avoid a big >> latency in case of let's say 100 hot standby. >> it was an idea, a concept to let the master write and update the nodes, like >> a queen bee ;) >> but I'm afraid it's not possible, so maybe future version of pg will do it, >> for now read from the master is my only solution. > > Well, Thomas Munro (adding him in CC) has sent for integration with > 9.6 a patch that would cover your need, by adding to > synchronous_commit a mode called 'apply', in which case a master would > wait for the transaction to be applied on standby before committing > locally: > http://www.postgresql.org/message-id/CAEepm=1fqkivL4V-OTPHwSgw4aF9HcoGiMrCW-yBtjipX9gsag@mail.gmail.com > Perhaps you could help with the review of the patch, this has stalled > a bit lately.
That patch (or something more sophisticated long those lines) is a small piece of a bigger puzzle, though it might be enough if you only have one standby, are prepared to block until manual intervention if that standby fails, and don't mind potentially lumpy apply performance. See also the work being done to separate wal writing from wal applying for smoother performance[1], and handle multiple synchronous standbys[2]. But there is another piece of the puzzle IMHO: how to know reliably that the standby that you are talking to guarantees causal consistency, while also allowing standbys to fail/drop out gracefully, and I'm currently working on an idea for that.
FYI I posted the resulting proposal and patch over on the -hackers list. Feedback, ideas, flames welcome as always.
