How would code after applying this patch behave if a recycled segment gets
renamed using the newest timeline (say 3) while we are still recovering from
a lower timeline (say 2)? In that case, since XLogFileReadAnyTLI returns
that recycled segment as the next segment to recover from, we get the error.
And since XLogFileReadAnyTLI iterates over expectedTLIs (whose head seems to
be recoveryTargetTLI at all times, is that right?), it will return that
wrong (recycled segment) in the first iteration itself.
The code for renaming the recycling segment remains unaffected by this
patch, right? That is, the code which assigns timelineID to newly created /
recycled segments is not changed.
(a snippet from CreateRestartPoint() )
/* * Update ThisTimeLineID to the recovery target timeline, so that * we install any recycled segments on the correct
timeline.*/
>>>> ThisTimeLineID = GetRecoveryTargetTLI(); <<<<<
RemoveOldXlogFiles(_logId, _logSeg, endptr);
/* * Make more log segments if needed. (Do this after recycling old log * segments, since that may supply some of the
neededfiles.) */
PreallocXlogFiles(endptr);
So, would we still get a similar behavior (wherein the wrongly named
recycled segments are produced) and cause the error to happen again? Do we
need to look here?
What do you think?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Failing-start-up-archive-recovery-at-Standby-mode-in-PG9-2-4-tp5753110p5753353.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.