On Mon, Jan 23, 2012 at 10:29 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Fri, Jan 20, 2012 at 11:34 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On Fri, Jan 20, 2012 at 12:54 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> Thanks for the review!
>>> On Fri, Jan 20, 2012 at 8:15 PM, Simon Riggs <simon(at)2ndquadrant(dot)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
>>>> 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?
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. I'll proceed
to commit for this now.
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2012-01-23 13:11:10|
|Subject: Re: Online base backup from the hot-standby|
|Previous:||From: Robert Haas||Date: 2012-01-23 13:09:11|
|Subject: Re: PG-Strom - A GPU optimized asynchronous executor module|