Re: [BUG] non archived WAL removed during production crash recovery
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, jgdr@dalibo.com
Cc: pgsql-bugs@lists.postgresql.org, michael@paquier.xyz
Date: 2020-04-02T05:19:15Z
Lists: pgsql-bugs, pgsql-hackers
On 2020/04/02 13:07, Kyotaro Horiguchi wrote: > Sorry, it was quite ambiguous. > > At Thu, 02 Apr 2020 13:04:43 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in >> At Wed, 1 Apr 2020 18:17:35 +0200, Jehan-Guillaume de Rorthais <jgdr@dalibo.com> wrote in >>> Please, find in attachment a patch implementing this. >> >> The patch partially reintroduces the issue the patch have >> fixed. Specifically a standby running a crash recovery wrongly marks a >> WAL file as ".ready" if it is extant in pg_wal without accompanied by >> .ready file. > > The patch partially reintroduces the issue the commit 78ea8b5daa have > fixed. Specifically a standby running a crash recovery wrongly marks a > WAL file as ".ready" if it is extant in pg_wal without accompanied by > .ready file. On second thought, I think that we should discuss what the desirable behavior is before the implentation. Especially what's unclear to me is whether to remove such WAL files in archive recovery case with archive_mode=on. Those WAL files would be required when recovering from the backup taken before that archive recovery happens. So it seems unsafe to remove them in that case. Therefore, IMO that the patch should change the code so that no unarchived WAL files are removed not only in crash recovery but also archive recovery. Thought? Of course, this change would lead to the issue that the past unarchived WAL files keep remaining in the case of warm-standby using archive recovery. But this issue looks unavoidable. If users want to avoid that, archive_mode should be set to always. Also I'm a bit wondering if it's really safe to remove such unarchived WAL files even in the standby case with archive_mode=on. I would need more time to think that. >> Perhaps checking '.ready' before the checking for archive-mode would >> be sufficient. >> >>> Plus, I added a second commit to add one test in regard with this bug. >>> >>>> Another is to make the startup process remove .ready file if necessary. >>> >>> I'm not sure to understand this one. I was thinking to make the startup process remove such unarchived WAL files if archive_mode=on and StandbyModeRequested/ArchiveRecoveryRequested is true. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Commits
-
Fix interpolation in test name.
- e16e9204692c 11.10 landed
- af2d09fa1c28 12.5 landed
- 6fb1c5b52826 13.0 landed
- 47a3a1c3d498 14.0 landed
-
Add more TAP coverage for archive status with crash recovery of standbys
- ebf6de869276 13.0 landed
-
Fix handling of WAL segments ready to be archived during crash recovery
- 9eff11653962 9.5.22 landed
- c2d8ae0dfe84 9.6.18 landed
- 02657c42199c 10.13 landed
- 2d24ca00b750 11.8 landed
- 22db5269bfa1 12.3 landed
- 4e87c4836ab9 13.0 landed
-
Fix WAL recycling on standbys depending on archive_mode
- 78ea8b5daab9 12.0 cited