On Wed, Oct 14, 2015 at 6:00 PM, Alexander Korotkov wrote: > On Sat, Sep 19, 2015 at 2:25 AM, Michael Paquier wrote: >> Alexander, what do you think about that? I think that we should be >> able to rewind with for example node 2 as target and node 3 as source, >> and vice-versa as per the example you gave even if both nodes are on >> the same timeline, just that they forked at a different point. Could >> you test this particular case? Using my script, simply be sure to >> switch archive_mode to on/off depending on the node, aka only 3 and 4 >> do archiving. > > I think relying on different fork point is not safe enough. Imagine more > complex case. > > 1 > / \ > 2 3 > | | > 4 5 > > At first, nodes 2 and 3 are promoted at the same point and they both get > timeline 2. > Then nodes 4 and 5 are promoted at different points and they both get > timeline 3.
You mean that those nodes get the history file generated at timeline 2 by either 2 or 3 here I guess. > Then we can try to rewind node 4 with node 5 as the source or vice versa. In > this case we can't find collision of timeline 2. > The same collision could happen even when source and target are on the > different timeline number. However, having the on the same timeline numbers > is suspicious enough to disallow it until we have additional checks. Check. > I could propose following plan: > Commit this patch without allowing rewind when target and source are on the > same timelines. > Make additional checks for distinguish different timelines with the same > numbers. That's the addition of the 8-byte timeline ID in the XLOG segment header. We would need to store it in the control data file as well. > Allow rewind when target and source are on the same timelines. Check. This relies on the fact that a portion of the nodes select their new timeline without knowing the previous history. I believe that this does not exist much in a perfect world, but I've seen enough setups messed up to conclude that this would surely exist on the field. In short this plan looks fine to me. Your patch is very valuable even with this same-timeline restriction in place. -- Michael -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers