Post-Merge Table Fragments

In a NON-BLOCKING merge, the most recently committed data from the RLV store is written to the IQ main store to create a new table-level version of the RLV-enabled table. This new table-level version combines the previous table-level version plus the changes from the RLV store (the in-memory changes from committed transactions). Uncommitted transactions may reference snapshot versions on the pre-merged RLV store. These fragments are held in-memory until the transactions terminate.

The merge operation itself has an impact on the RLV store:

When the merge starts, a new RLV store instance is created.
From then on, all data changes go to the new instance.
The committed changes of the original instance of the RLV store are merged into the IQ main store.
Then the merge ends.

An active merge operation uses two RLV store disjoint instances. The original RLV store instance contains all committed changes done before the beginning of the merge; the new RLV store contains all changes done after the beginning of the merge. Because of any open transactions residing in the original instance (transactions begun, but not committed before the merge), the original instance is preserved until all transactions have been committed.

For BLOCKING merges the scenario is much simpler. There are no uncommitted transactions referencing snapshot versions on the pre-merged RLV store, nor are there any data changes happening while the merge is running. Hence, when a BLOCKING merge completes, there is only ever a single, empty RLV table fragment.