> When the standby restarts after it crashes during recovery, it always
> checks whether recovery has reached the backup end location by
> using minRecoveryPoint even though the standby doesn't start from
> the backup. This looks odd.
Certainly.
But, in this case, the state before recovery starts is lost.
Therefore, postgres can not see that the backup got from whether
standby server or master.
What should?
Should use pg_control?Ex. * Add 'Where to get backup' to pg_control. (default 'none') * When recovery starts, it
checksit whether 'none'. * When minRecoveryPoint equals 0/0, change 'master'. * When minRecoveryPoint do not
equals0/0, change 'slave'. * When it reached the end of recovery, change 'none' .
> - XLogRecPtrIsInvalid(ControlFile->backupStartPoint))
> + (XLogRecPtrIsInvalid(ControlFile->backupStartPoint) ||
> + reachedControlMinRecoveryPoint == true))
> The flag 'reachedControlMinRecoveryPoint' is really required? When recovery
> reaches minRecoveryPoint, ControlFile->backupStartPoint is reset to zero. So
> we can check whether recovery has reached minRecoveryPoint or not by only
> doing XLogRecPtrIsInvalid(ControlFile->backupStartPoint). No?
Yes.
'reachedControlMinRecoveryPoint' is unnecessary.
> We should check if recovery has reached minRecoveryPoint before calling
> CheckRecoveryConsistency() after reading new WAL record? Otherwise,
> even if recovery has reached minRecoveryPoint, the standby cannot think
> that it's in consistent state until it reads new WAL record.
This is a same sequence with a case of backup end location.
It should be no changed.
> + if (XLByteLT(ControlFile->minRecoveryPoint, EndRecPtr))
> + ControlFile->minRecoveryPoint = EndRecPtr;
> Why does ControlFile->minRecoveryPoint need to be set to EndRecPtr?
Yes.
I delete it.
--------------------------------------------
Jun Ishizuka
NTT Software Corporation
TEL：045-317-7018
E-Mail: ishizuka.jun@po.ntts.co.jp
--------------------------------------------