On Thu, Mar 3, 2016 at 3:34 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > That's one of my concerns about this patch now: it is trying to do too > much. I think that there is definitely a need for both things: > applications may be fine to pay the lagging price when remote_apply is > used by not having an extra error handling layer, or they cannot > accept a perhaps large of lag and are ready to have an extra error > handling layer to manage read failures on standbys. So I would > recommend a split to begin with: > 1) Addition of remote_apply in synchronous_commit, which would be > quite a simple patch, and I am convinced that there are benefits in > having that. Compared to the previous patch sent, a standby message is > sent back to the master once COMMIT has been applied, accelerating > things a bit.
Hm. Looking now at http://www.postgresql.org/message-id/canp8+j+jcpnoojc-kqltt4pdyox2sq6wywqcsy6aahwkvna...@mail.gmail.com it would be nice to get a clear solution for it first, though the use of signals to wake up the WAL receiver and enforce it to send a new LSN apply position back to the master to unlock it asap does not look very appealing. Seeing that no patch has been sent for 9.6 regarding that, it would be better to simply drop this code from the causal-read patch perhaps... -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
