From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, amit(dot)kapila16(at)gmail(dot)com, dilipbalaut(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Problem while setting the fpw with SIGHUP |
Date: | 2018-04-11 20:24:14 |
Message-ID: | 20180411202414.GA32449@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 11, 2018 at 02:09:48PM +0300, Heikki Linnakangas wrote:
> I think the new behavior where the GUC only takes effect at next checkpoint
> is OK. It seems quite intuitive.
>
> > [rebased patch version]
>
> Looks good at a quick glance. Assuming no objections from others, I'll take
> a closer look and commit tomorrow. Thanks!
Sorry for not following up closely this thread lately.
+ /*
+ * If full_page_writes has been turned off, issue XLOG_FPW_CHANGE before
+ * the flag actually takes effect. No lock is required since checkpointer
+ * is the only updator of shared fullPageWrites after recovery is
+ * finished. Both shared and local fullPageWrites do not change before the
+ * next reading below.
+ */
+ if (Insert->fullPageWrites && !fullPageWrites)
+ {
+ XLogBeginInsert();
+ XLogRegisterData((char *) (&fullPageWrites), sizeof(bool));
+ XLogInsert(RM_XLOG_ID, XLOG_FPW_CHANGE);
+ }
This is not actually true. If a fallback_promote is used, then
CreateCheckPoint() is called by the startup process which is in charge
of issuing the end-of-recovery checkpoint, and not the checkpointer. So
I still fail to see how a no-lock approach is fine except if we remove
fallback_promote?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-04-11 20:28:33 | Re: Bugs in TOAST handling, OID assignment and redo recovery |
Previous Message | Daniel Gustafsson | 2018-04-11 20:21:29 | Re: Gotchas about pg_verify_checksums |