On Mon, Jan 15, 2018 at 12:13:46AM +0000, Dylan Luong wrote: > The content of the history file 00000006.history is: Please do not top-post. This breaks the logic of the thread. > $ more 00000006.history > 1 2CE/8A000098 no recovery target specified > 2 2CE/FF974EF0 no recovery target specified > 3 2CF/51000098 no recovery target specified > 4 2D1/C90ACD88 no recovery target specified > 5 383/C0790E50 no recovery target specified So indeed the timeline has forked at 0000000500000383000000C0, which is what the .partial file also means. > Here are the last few archive file of the old timeline (old master): > > 0000000500000383000000BD > 0000000500000383000000BE > 0000000500000383000000BF > 0000000500000383000000C0 > 0000000500000383000000C1 > > Here are the first few archive files of the new timeline (new master): > 0000000500000383000000C0.partial > 0000000600000383000000C0 > 0000000600000383000000C1 > 0000000600000383000000C2 > 0000000600000383000000C3 > > Looks like it has folked at C0. > But why is the new slave asking for 0000000600000383000000BE on > timeline during the restore after the pg_rewind? And not from C0? The rewound standby needs to recover from the point of the last checkpoint where timeline forked. So I can guess that this record is located in segment 0000000500000383000000BE. Now I find strange that the standby requests for a segment on the new timeline 5, while it should start at TLI 5. Are you sure that the standby had the means been able to fetch segment 0000000500000383000000BE? Something looks weird from your operational point of view with your archives.. -- Michael
Attachment:
signature.asc
Description: PGP signature
