Re: Problem while setting the fpw with SIGHUP

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: michael(at)paquier(dot)xyz
Cc: hlinnaka(at)iki(dot)fi, 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-12 01:34:30
Message-ID: 20180412.103430.133595350.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello. Thanks to Heikkit for picking this up and thanks for the
commnet to Michael.

# The attached is changed only in a comment, and rebased.

At Thu, 12 Apr 2018 05:24:14 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in <20180411202414(dot)GA32449(at)paquier(dot)xyz>
> 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?

Checkpointer never calls CreateCheckPoint while
RecoveryInProgress() == true. In other words, checkpointer is not
an updator of shared FPW at the time StartupXLOG calls
CreateCheckPoint for fallback_promote.

The comment may be somewhat confusing that it is written
there. The point is that checkpointer and StartupXLOG are
mutually excluded on updating shared FPW by
SharedRecoveryInProgress flag.

| * If full_page_writes has been turned off, issue XLOG_FPW_CHANGE before
| * the flag actually takes effect. Checkpointer never calls this function
| * before StartupXLOG() turns off SharedRecoveryInProgress so there's no
| * window where checkpointer and startup processes - the only updators of
| * the flag - can update shared FPW simultaneously. Thus no lock is
| * required here. Both shared and local fullPageWrites do not change
| * before the next reading below.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
v2-0001-Change-FPW-handling.patch text/x-patch 30.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-04-12 01:55:37 Re: Native partitioning tablespace inheritance
Previous Message Peter Eisentraut 2018-04-12 00:23:31 Re: Bugs in TOAST handling, OID assignment and redo recovery