On Tue, Sep 7, 2010 at 4:06 PM, marcin mank <marcin.m...@gmail.com> wrote: > On Tue, Sep 7, 2010 at 5:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> We can *not* allow the slave to replay WAL ahead of what is known >> committed to disk on the master. The only way to make that safe >> is the compare-notes-and-ship-WAL-back approach that Robert mentioned. >> >> If you feel that decoupling WAL application is absolutely essential >> to have a credible feature, then you'd better bite the bullet and >> start working on the ship-WAL-back code. >> > > In the mode where it is not required that the WAL is applied (only > sent to the slave / synced to slave disk) one alternative is to have a > separate pointer to the last WAL record that can be safely applied on > the slave. Then You can send the un-synced WAL to the slave (while > concurrently syncing it on the master). When both the slave an the > master sync complete, one can give the client a commit notification, > increase the pointer, and send it to the slave (it would be a separate > WAL record type I guess). > > In case of master failure, the slave can discard the un-applied WAL > after the pointer.
But the pointer on the slave has to be fsync'd to make it persistent, which likely takes roughly the same amount of time as fsync-ing the WAL itself. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
