On Tue, Sep 8, 2015 at 1:11 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
> On Thu, Sep 3, 2015 at 12:02 AM, Fujii Masao <masao.fu...@gmail.com> > wrote: >> >> One idea is to change the standby so that it manages the locations >> that the backends in "apply" mode are waiting for in the master, >> and to make the startup process wake the walreceiver up whenever >> the replay location reaches either of those locations. In this idea, >> walreceiver sends back the "apply" location to the master only when >> needed. >> > > Hmm. So maybe commit records could have a flag saying 'someone is waiting > for this to commit to apply', and the startup process's apply loop would > only bother to signal the walreceiver if it sees that flag. I will try > that. > Here is a version that does that, using a bit in xinfo to request apply feedback from standbys when running with synchronous_commit = apply. I am not very happy with the way that xact_redo communicates with the main apply loop when it sees that bit, through calls to XLogAppliedSynchronousCommit (essentially a global variable), but I couldn't immediately see a better way to get information out of xact_redo into the apply loop without changing the rm_redo interface. Perhaps xinfo is the wrong place for that information. Thoughts? -- Thomas Munro http://www.enterprisedb.com
synchronous-commit-apply-v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
