Re: Online base backup from the hot-standby

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Online base backup from the hot-standby
Дата
Msg-id CAHGQGwFwrsJMdnatn_VbktCDKstrTh7LMgiKPvrdLRzdfaOVdg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Online base backup from the hot-standby  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Online base backup from the hot-standby  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Mon, Jan 23, 2012 at 10:11 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Mon, Jan 23, 2012 at 10:29 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Fri, Jan 20, 2012 at 11:34 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> On Fri, Jan 20, 2012 at 12:54 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>>> Thanks for the review!
>>>>
>>>> On Fri, Jan 20, 2012 at 8:15 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>>>> I'm looking at this patch and wondering why we're doing so many
>>>>> press-ups to ensure full_page_writes parameter is on. This will still
>>>>> fail if you use a utility that removes the full page writes, but fail
>>>>> silently.
>>>>>
>>>>> I think it would be beneficial to explicitly check that all WAL
>>>>> records have full page writes actually attached to them until we
>>>>> achieve consistency.
>>>>
>>>> I agree that it's worth adding such a safeguard. That can be a self-contained
>>>> feature, so I'll submit a separate patch for that, to keep each patch small.
>>>
>>> Maybe, but you mean do this now as well? Not sure I like silent errors.
>>
>> If many people think the patch is not acceptable without such a safeguard,
>> I will do that right now. Otherwise, I'd like to take more time to do
>> that, i.e.,
>> add it to 9.2dev Oepn Items.
>
>> I've not come up with good idea. Ugly idea is to keep track of all replays of
>> full_page_writes for every buffer pages (i.e., prepare 1-bit per buffer page
>> table and set the specified bit to 1 when full_page_writes is applied),
>> and then check whether full_page_writes has been already applied when
>> replaying normal WAL record... Do you have any better idea?
>
> Not sure.
>
> I think the only possible bug here is one introduced by an outside utility.
>
> In that case, I don't think it should be the job of the backend to go
> too far to protect against such atypical error. So if we can't solve
> it fairly easily and with no overhead then I'd say lets skip it. We
> could easily introduce a bug here just by having faulty checking code.
>
> So lets add it to 9.2 open items as a non-priority item.

Agreed.

> I'll proceed to commit for this now.

Thanks a lot!

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: WAL Restore process during recovery
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: WAL Restore process during recovery