On Sat, Jun 15, 2013 at 10:34 PM, Amit kapila <amit.kapila@huawei.com> wrote:
>
> On Saturday, June 15, 2013 1:19 PM Sawada Masahiko wrote:
> On Fri, Jun 14, 2013 at 10:15 PM, Amit Kapila <amit.kapila@huawei.com> wrote:
>> On Friday, June 14, 2013 2:42 PM Samrat Revagade wrote:
>>> Hello,
>>
>>>> We have already started a discussion on pgsql-hackers for the problem of
>>>> taking fresh backup during the failback operation here is the link for that:
>>>>
>>>>
>>>> http://www.postgresql.org/message-id/CAF8Q-Gxg3PQTf71NVECe-6OzRaew5pWhk7yQtb
>>>> JgWrFu513s+Q@mail.gmail.com
>>>>
>>>> Let me again summarize the problem we are trying to address.
>>>
>>>
>>> How will you take care of extra WAL on old master during recovery. If it
>>> plays the WAL which has not reached new-master, it can be a problem.
>
>> you means that there is possible that old master's data ahead of new
>> master's data.
>
> I mean to say is that WAL of old master can be ahead of new master. I understood that
> data files of old master can't be ahead, but I think WAL can be ahead.
>
>> so there is inconsistent data between those server when fail back. right?
>> if so , there is not possible inconsistent. because if you use GUC option
>> as his propose (i.g., failback_safe_standby_mode = remote_flush),
>> when old master is working fine, all file system level changes aren't
>> done before WAL replicated.
>
> Would the propose patch will take care that old master's WAL is also not ahead in some way?
> If yes, I think i am missing some point.
yes it will happen that old master's WAL ahead of new master's WAL as you said.
but I think that we can solve them by delete all WAL file when old
master starts as new standby.thought?
Regards,
-------
Sawada Masahiko