On Tue, Sep 7, 2010 at 4:06 PM, marcin mank <marcin.mank@gmail.com> wrote:
> On Tue, Sep 7, 2010 at 5:17 PM, Tom Lane <tgl@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