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 needed files.) */ 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
