Re: Problem while setting the fpw with SIGHUP

At Tue, 24 Apr 2018 08:52:17 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in <20180423235217(dot)GB1570(at)paquier(dot)xyz>
> On Mon, Apr 23, 2018 at 12:21:04PM -0400, Robert Haas wrote:
> > Fine, but that doesn't answer the question of whether we actually need
> > to or should change the behavior in the first place.
>
> Per the last arguments that would be "No, we don't want to change it as
> it would surprise some users":
> https://www.postgresql.org/message-id/20180420010402.GF2024@paquier.xyz

The answer is that the change of behavior is not required to fix
the bug. So I'm fine with applying only (0001 and) 0002 here.

https://www.postgresql.org/message-id/20180420010402.GF2024@paquier.xyz

One reason that I introduced the "restriction" was that it was
useful to avoid concurrent udpate of the flag. It is now avoided
in another way.

Just my opinion on the behavior follows.

I don't think anyone confirms that FPI come back after switching
full_page_writes (one of the reason is it needs pg_waldump).
pg_start/stop_backup() on standby says that "You need to turn on
FPW, then do checkpoint". It suggests that FPI's don't work
before the next checkpoint. If we keep the current behavior, the
documentation might need an additional phrase something like "FPW
ensures that data is protected from partial writes after the next
chackpoint starts". On the other hand honestly I don't have
confidence that the WAL reduction worth the additional complexity
by 0003.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center