Re: Problem while setting the fpw with SIGHUP

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, Dilip Kumar <dilipbalaut@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-04-13T03:01:02Z
Lists: pgsql-hackers
On Fri, Apr 13, 2018 at 6:59 AM, Michael Paquier <michael@paquier.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 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.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


Commits

  1. Fix assertion failure when updating full_page_writes for checkpointer.

  2. Attach FPI to the first record after full_page_writes is turned on.

  3. Revamp the WAL record format.

  4. Move the backup-block logic from XLogInsert to a new file, xloginsert.c.