On Mon, Jan 23, 2012 at 10:11 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Mon, Jan 23, 2012 at 10:29 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> On Fri, Jan 20, 2012 at 11:34 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> On Fri, Jan 20, 2012 at 12:54 PM, Fujii Masao <masao.fu...@gmail.com> wrote: >>>> Thanks for the review! >>>> >>>> On Fri, Jan 20, 2012 at 8:15 PM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
