Re: Problem while setting the fpw with SIGHUP

At Fri, 13 Apr 2018 08:31:02 +0530, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote in <CAA4eK1LVFpLf=d-7XmfwhLv7Xu53pU0bGU=wVrYWSRU4XSsyHQ(at)mail(dot)gmail(dot)com>
> On Fri, Apr 13, 2018 at 6:59 AM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > On Thu, Apr 12, 2018 at 02:55:53PM -0400, Robert Haas wrote:
> >> I think it may actually be confusing. If you run pg_ctl reload and it
> >> reports that the value has changed, you'll expect it to have taken
> >> effect. But really, it will take effect at some later time.
> >
>
> +1. I also think it is confusing and it could be difficult for end
> users to know when the setting is effective.
>
> > It is true that sometimes some people like to temporarily disable
> > full_page_writes particularly when doing some bulk load of data to
> > minimize the effort on WAL, and then re-enable it just after doing
> > the inserting this data.
> >
> > Still does it matter when the change is effective? By disabling
> > full_page_writes even temporarily, you accept the fact that this
> > instance would not be safe until the next checkpoint completes. The
> > instance even finishes by writing less unnecessary WAL data if the
> > change is only effective at the next checkpoint. Well, it is true that
> > this increases potential torn pages problems but the user is already
> > accepting that risk if a crash happens until the next checkpoint then it
> > exposes itself to torn pages anyway as it chose to disable
> > full_page_writes.

I still don't think that enabling FPW anytime is useful but
disabling seems useful as I mentioned upthread.

The problem was checkpointer changes the flag anytime including
recovery time. Startup process updates the same flag at the end
of recovery but before publicated. Letting checkpointer change
the flag only at checkpoint time is a straightforward way to
avoid conflicts with startup process.

I reconsider a bit and came up with the thought that we could
just skip changing shared FPW in checkpointer until recovery
ends, then update the flag after recovery end (perhaps at
checkpoint time in major cases). In this case, FPI is attached
from REDO point of the first checkpoint (not restartpoint) or a
bit earlier, then FPW can be flipped at any time. I'll come up
with that soon.

> I think this means that is will be difficult for end users to predict
> unless they track the next checkpoint which isn't too bad, but won't
> be convenient either.

Looking checkpiont record is enough to know wheter the checkpoint
is protected by FPW eough, but I agree that such strictness is
not crutial.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center