From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | michael(at)paquier(dot)xyz, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Problem while setting the fpw with SIGHUP |
Date: | 2018-04-06 12:29:58 |
Message-ID: | CAA4eK1+1zULC52G_EyNcrrxFCmBi4NUuA1CoQAKu2FFPai_Teg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 6, 2018 at 1:50 PM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> Hello.
>
> At Wed, 04 Apr 2018 17:26:46 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20180404(dot)172646(dot)238325981(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
>> > In general, I was wondering why in the first place this variable
>> > (full_page_writes) is a SIGHUP variable? I think if the user tries to
>> > switch it to 'on' from 'off', it won't guarantee the recovery from
>> > torn pages. Yeah, one can turn it to 'off' from 'on' without any
>> > problem, but as the reverse doesn't guarantee anything, it can confuse
>> > users. What do you think?
>>
>> I tend to agree with you. It works as expected after the next
>> checkpoint. So define the variable as "it can be changed any time
>> but has an effect at the next checkpoint time", then remove
>> XLOG_FPW_CHANGE record. And that eliminates the problem of
>> concurrent calls since the checkpointer becomes the only modifier
>> of the variable. And the problematic function
>> UpdateFullPageWrites also no longer needs to write a WAL
>> record. The information is conveyed only by checkpoint records.
>
> I noticed that XLOG_FPW_CHANGE(fpw=false) is still required by
> pg_start/stop_backup to know FPW's turning-off without waiting
> for the next checkpoint record. But XLOG_FPW_CHANGE(true) is not
> required since no one uses the information. It seems even harmful
> when it is written at the incorrect place.
>
> In the attached patch, shared fullPageWrites is updated only at
> REDO point
>
I am not completely sure if that is the right option because this
would mean that we are defining the new scope for a GUC variable. I
guess we should take the input of others as well. I am not sure what
is the right way to do that, but maybe we can start a new thread with
a proper subject and description rather than discussing this under
some related bug fix patch discussion. I guess we can try that after
CF unless some other people pitch in and share their feedback.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-04-06 12:30:28 | Re: [HACKERS] logical decoding of two-phase transactions |
Previous Message | Alvaro Herrera | 2018-04-06 12:24:34 | Re: [HACKERS] path toward faster partition pruning |