Re: Problem while setting the fpw with SIGHUP - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Problem while setting the fpw with SIGHUP
Date
Msg-id 20180413012952.GC1552@paquier.xyz
Whole thread Raw
In response to Re: Problem while setting the fpw with SIGHUP  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Problem while setting the fpw with SIGHUP  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Problem while setting the fpw with SIGHUP  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.

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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Instability in partition_prune test?
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] path toward faster partition pruning