forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commitfb886c1
committed
Fix possibility of creating a "phantom" segment after promotion.
When promoting a standby just after a XLOG_SWITCH record was replayed,and next segment(s) are already are locally available (via walsender,restore_command + trigger/recovery target), that segment couldaccidentally be recycled onto the past of the new timeline. Latercheckpointer would create a .ready file for it, assuming there was anerror during creation, and it would get archived. That causes troubleif another standby is later brought up from a basebackup from beforethe timeline creation, because it would try to read thesegment, because XLogFileReadAnyTLI just tries all possible timelines,which doesn't have valid contents. Thus replay would fail.The problem, if already occurred, can be fixed by removing the segmentand/or having restore_command filter it out.The reason for the creation of such "phantom" segments was, that afteran XLOG_SWITCH record the EndOfLog variable points to the beginning ofthe next segment, and RemoveXlogFile() used XLByteToPrevSeg().Normally RemoveXlogFile() doing so is harmless, because the lastsegment will still exist preventing InstallXLogFileSegment() fromcausing harm, but just after promotion there's no previous segment onthe new timeline.Fix that by using XLByteToSeg() instead of XLByteToPrevSeg().Author: Andres FreundReported-By: Greg BurekDiscussion:https://postgr.es/m/20170619073026.zcwpe6mydsaz5ygd@alap3.anarazel.deBackpatch: 9.2-, bug older than all supported versions1 parent780b3a4 commitfb886c1
1 file changed
+1
-1
lines changedLines changed: 1 addition & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
3974 | 3974 | | |
3975 | 3975 | | |
3976 | 3976 | | |
3977 | | - | |
| 3977 | + | |
3978 | 3978 | | |
3979 | 3979 | | |
3980 | 3980 | | |
| |||
0 commit comments
Comments
(0)