Re: [BUG] non archived WAL removed during production crash recovery
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, masao.fujii@oss.nttdata.com, pgsql-bugs@lists.postgresql.org
Date: 2020-04-21T02:15:01Z
Lists: pgsql-bugs, pgsql-hackers
On Mon, Apr 20, 2020 at 02:22:35PM +0200, Jehan-Guillaume de Rorthais wrote: > The problem is that we would have to read the controldata file each time we > wonder if a segment should be archived/removed. Moreover, the controldata > file might not be in sync quickly enough with the real state for some other > code path or futur needs. I don't think that this is what Horiguchi-san meant here. What I got from his previous message would be to be to copy the shared value from the control file when necessary, and have the shared state use only a subset of the existing values of DBState, aka: - DB_IN_CRASH_RECOVERY - DB_IN_ARCHIVE_RECOVERY - DB_IN_PRODUCTION Still, that sounds wrong to me because then somebody would be tempted to change the shared value thinking that things like DB_SHUTDOWNING, DB_SHUTDOWNED_* or DB_STARTUP are valid but we don't want that here. Note that there may be a case for DB_STARTUP to be used in XLOGShmemInit(), but I'd rather let the code use the safest default, DB_IN_CRASH_RECOVERY to control that we won't remove .ready files by default until the startup process sees fit to do the actual switch depending on the checkpoint record lookup, if archive recovery was actually requested, etc. > Indeed, Benoît Lobréau reported this behavior to me. Noted. Thanks for the information. I don't think that I have ever met Benoît in person, do I? Tell him that I owe him one beer or a beverage of his choice when we meet IRL, and that he had better use this message-id to make me keep my promise :) -- Michael
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