From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New sync commit mode remote_write |
Date: | 2012-04-24 16:21:49 |
Message-ID: | CAMkU=1xcC64nY3T_aVCYw0M78iiFEWQVvOaSkbBnQKpHdXzFJQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 19, 2012 at 11:50 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On 4/19/12, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> The work around would be for the master to refuse to automatically
>> restart after a crash, insisting on a fail-over instead (or a manual
>> forcing of recovery)?
>
> I suppose that would work, but I think Simon's idea is better: don't
> let the slave replay the WAL until either (a) it's promoted or (b) the
> master finishes the fsync. That boils down to adding some more
> handshaking to the replication protocol, I think.
Alternative c) is that the master automatically recovers from a crash,
but doesn't replay that particular wal record because it doesn't find
it on disk, so the slave has to be instructed to throw it away. (Or
perhaps the slave could feed the wal back to the master, so the master
could replay it?)
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2012-04-24 16:30:27 | Re: Timsort performance, quicksort (was: Re: Memory usage during sorting) |
Previous Message | Robert Haas | 2012-04-24 16:00:16 | Re: New sync commit mode remote_write |