Currently, block-merging is configurable to be either lazy or non-lazy. However non-lazy sequence is incorrect – it will be merging blocks before actually rolling back reverted ones. To make sure users do not accidentally hit this issue, we need to revisit MOR block merging sequence and make sure that following invariants are upheld
Blocks are merged in 2 passes:
First we load all blocks, while dropping rolled back ones, then
We merge them in another forward-pass
We should try to avoid having 2 merging sequences and instead consolidate on just one: right now we have "block + block", and "base + block", but we should be able to just get away with just the latter (this will simplify merging sequence quite substantially, for ex in respect to handling of deletions)
JIRA info
Comments
18/Jan/23 20:33;alexey.kudinkin;This is addressed in the new scanV2 implementation;;;
Currently, block-merging is configurable to be either lazy or non-lazy. However non-lazy sequence is incorrect – it will be merging blocks before actually rolling back reverted ones. To make sure users do not accidentally hit this issue, we need to revisit MOR block merging sequence and make sure that following invariants are upheld
Blocks are merged in 2 passes:
First we load all blocks, while dropping rolled back ones, then
We merge them in another forward-pass
We should try to avoid having 2 merging sequences and instead consolidate on just one: right now we have "block + block", and "base + block", but we should be able to just get away with just the latter (this will simplify merging sequence quite substantially, for ex in respect to handling of deletions)
JIRA info
Comments
18/Jan/23 20:33;alexey.kudinkin;This is addressed in the new scanV2 implementation;;;