On Thu, 2018-10-11 at 06:35 +0200, Laurenz Albe wrote: > magodo wrote: > > OK... Just take another example: > > > > A B > > BASE-----+-----+------o1 (recover to > > A) 1 > > | | C > > +.....|.......----+---o2 (regret, recover to > > B) 2 > > | | > > +...........|..------o3 (regret again, recover to > > C) 3 > > | > > +........-- > > -- 4 > > > > > > Suppose I'm at "o3" and want to recover to point "C". Because I > > want to > > recover to the first timeline which covers this time point, it > > means I > > wish to recover to timeline 2. > > Ah, I finally understand your question. > > You assume tht timeline 1 and 2 have ended (that's how you drew it), > and that consequently timeline 3 is the "earliest existing" timeline, > so why doesn't PostgreSQL choose that one automatically? > > Even though you drew it that way, timeline 1 and 2 have not ended, in > a way. There may be more on them. How should PostgreSQL know what > is > the last WAL entry on a certain timeline? For that, it would have to > restore and examine *all* WAL segments on that timeline until that > fails. > > But that is unreasonable because of the potential amount of time > and work involved. Rather, PostgreSQL has to decide at the point > where > timeline 2 branches off which one it should follow. > > Yours, > Laurenz Albe Thank God I finnally conveied my meaning :) For one cluster, if , for example, it recovered to "A" at "o1", then the switched WAL(in case of stop-then-recover) or .partial corresponding WAL(in case of promote) is the last WAL of the timeline1, and it makes no sense to consider timeline1 will continue grow after "o1", because it has ended. You meantioned: "There may be more on them.". Would you please give me an example? I must have missed something out... --- Magodo
