On Wed, Sep 19, 2018 at 10:50 AM Michael Paquier <michael@paquier.xyz> wrote:
> > Agreed. "If we need to do that in the start process," we need to
> > change the shared flag and issue FPW_CHANGE always when the
> > database state is different from configuration file, regardless
> > of what StartXLOG() did until the point.
>
> Definitely my mistake here. Attached is a patch to show what I have in
> mind by making sure that the startup process generates a record even
> after switching full_page_writes when started normally. This removes
> the condition based on InRecovery, and uses a new argument for
> UpdateFullPageWrites() instead. Your test case,as well as what I do
> manually for testing, pass without triggering the assertion.
>
This will fix the previous problem reported by me but will lead to
some other behavior change. If somebody toggles the full_page_writes
flag before crash recovery, then it will log the XLOG_FPW_CHANGE
record, but that was not the case without your patch.
> When I see your patch, I actually see the same kind of logic as what I
> propose which is summarized in two points, and that's a good thing:
> a) Avoid the allocation in the critical section.
> b) Avoid two processes to call UpdateFullPageWrites at the same time.
I think, in this case, it might be advisable to just fix the problem
(a) which is what has been reported originally in the thread and
AFAICS, the fix for that is clear as compared to the problem (b). If
you agree, then we can discuss what is the best fix for the first
problem (a).
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
