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
-
Fix assertion failure when updating full_page_writes for checkpointer.
- 85cc9c4e2da8 9.5.15 landed
- e315bd7db96a 9.6.11 landed
- 8256d7ae9ee3 10.6 landed
- 6c8671bc395c 11.0 landed
- a86bf6057edf 12.0 landed
-
Attach FPI to the first record after full_page_writes is turned on.
- 47a589c1fe35 9.5.15 landed
- fd4f2af774db 9.6.11 landed
- ede7d8192ca3 10.6 landed
- ff4220ead2c8 11.0 landed
- bc153c941d2e 12.0 landed
-
Revamp the WAL record format.
- 2c03216d8311 9.5.0 cited
-
Move the backup-block logic from XLogInsert to a new file, xloginsert.c.
- 2076db2aea76 9.5.0 cited