From: | marcin mank <marcin(dot)mank(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Synchronization levels in SR |
Date: | 2010-09-07 20:06:03 |
Message-ID: | AANLkTi=-iHTXfTcxY2L-CX45Kuhfwnu5TS3kx5vSsJ3H@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 7, 2010 at 5:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
Greetings
marcin
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-09-07 20:06:55 | Re: git: uh-oh |
Previous Message | Jeff Davis | 2010-09-07 19:41:51 | Re: "Freezing" per-role settings |