- 28 Dec, 2016 3 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
- 27 Dec, 2016 28 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
- 23 Dec, 2016 4 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
- 22 Dec, 2016 3 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
* origin/master: storage: start replicating the partition which is furthest behind master: fix possibly wrong knowledge of cells' backup_tid when resuming backup Minor comment/doc changes
-
- 21 Dec, 2016 2 commits
-
-
Kirill Smelkov authored
-
Julien Muchembled authored
This fixes the following case when the backup is far behing the upstream DB, and there are transactions being committed at the same time: 1. replicate partition 0 2. replicate partition 0 3. replicate partition 1 4. replicate partition 0 5. replicate partition 1 6. replicate partition 2 7. replicate partition 0 ... and so on in a quadratic way. When the upstream activity was too high, the backup could even be stuck looping on the first partitions.
-