At Tue, 24 Apr 2018 08:52:17 +0900, Michael Paquier <mich...@paquier.xyz> wrote in <20180423235217.gb1...@paquier.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.gf2...@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.gf2...@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
