Remove unnecessary call to ReadCheckpointRecord().
It should always be the case that the last checkpoint record is still readable, because otherwise, a crash would leave us in a situation from which we can't recover. Therefore the test removed by this patch should always succeed. For it to fail, either there has to be a serious bug in the code someplace, or the user has to be manually modifying pg_wal while crash recovery is running. If it's the first one, we should fix the bug. If it's the second one, they should stop, or anyway they're doing so at their own risk. In neither case does a full checkpoint instead of an end-of-recovery record seem like a clear winner. Furthermore, rarely-taken code paths are particularly vulnerable to bugs, so let's simplify by getting rid of this one. Discussion: http://postgr.es/m/CA+TgmoYmw==TOJ6EzYb_vcjyS09NkzrVKSyBKUUyo1zBEaJASA@mail.gmail.com
This commit is contained in:
parent
3df93a6659
commit
1d919de5eb
|
@ -7917,33 +7917,21 @@ StartupXLOG(void)
|
|||
{
|
||||
if (LocalPromoteIsTriggered)
|
||||
{
|
||||
checkPointLoc = ControlFile->checkPoint;
|
||||
promoted = true;
|
||||
|
||||
/*
|
||||
* Confirm the last checkpoint is available for us to recover
|
||||
* from if we fail.
|
||||
* Insert a special WAL record to mark the end of recovery,
|
||||
* since we aren't doing a checkpoint. That means that the
|
||||
* checkpointer process may likely be in the middle of a
|
||||
* time-smoothed restartpoint and could continue to be for
|
||||
* minutes after this. That sounds strange, but the effect is
|
||||
* roughly the same and it would be stranger to try to come
|
||||
* out of the restartpoint and then checkpoint. We request a
|
||||
* checkpoint later anyway, just for safety.
|
||||
*/
|
||||
record = ReadCheckpointRecord(xlogreader, checkPointLoc, 1, false);
|
||||
if (record != NULL)
|
||||
{
|
||||
promoted = true;
|
||||
|
||||
/*
|
||||
* Insert a special WAL record to mark the end of
|
||||
* recovery, since we aren't doing a checkpoint. That
|
||||
* means that the checkpointer process may likely be in
|
||||
* the middle of a time-smoothed restartpoint and could
|
||||
* continue to be for minutes after this. That sounds
|
||||
* strange, but the effect is roughly the same and it
|
||||
* would be stranger to try to come out of the
|
||||
* restartpoint and then checkpoint. We request a
|
||||
* checkpoint later anyway, just for safety.
|
||||
*/
|
||||
CreateEndOfRecoveryRecord();
|
||||
}
|
||||
CreateEndOfRecoveryRecord();
|
||||
}
|
||||
|
||||
if (!promoted)
|
||||
else
|
||||
RequestCheckpoint(CHECKPOINT_END_OF_RECOVERY |
|
||||
CHECKPOINT_IMMEDIATE |
|
||||
CHECKPOINT_WAIT);
|
||||
|
|
Loading…
Reference in New Issue