Skip to content
Snippets Groups Projects
  • Georgiy Lebedev's avatar
    56cf737c
    memtx: rework transaction rollback · 56cf737c
    Georgiy Lebedev authored
    When we rollback a transaction statement, we relink its read trackers
    to a newer story in the history chain, if present (6c990a7b), but we do not
    handle the case when there is no newer story.
    
    If there is an older story in the history chain, we can relink the
    rollbacked story's reader to it, but if the rollbacked story is the
    only one left, we need to retain it, because it stores the reader list
    needed for conflict resolution — such stories are distinguished by the
    rollbacked flag, and there can be no more than one such story located
    strictly at the end of a given history chain (which means a story can be
    fully unlinked from some indexes and present at the end of others).
    
    There are several nuances we need to account for:
    
    Firstly, such rollbacked stories must be impossible to read from an index:
    this is ensured by `memtx_tx_story_is_visible`.
    
    Secondly, rollbacked transactions need to be treated as prepared with
    stories that have `add_psn == del_psn`, so that they are correctly deleted
    during garbage collection.
    
    After this logical change we have the following partially ordered set over
    tuple stories:
    ———————————————————————————————————————————————————————> serialization time
    |- - - - - - - -|— — — — — -|— — — — — |— — — — — — -|— — — — — — — -
    | No more than  | Committed | Prepared | In-progress | One dirty
    | one rollbacked|           |          |             | story in index
    | story         |           |          |             |
    |- - - - - - - -|— — — — — -| — — — — —|— — — — — — -|— — — — — — — —
    
    Closes #7343
    
    NO_DOC=bugfix
    56cf737c
    History
    memtx: rework transaction rollback
    Georgiy Lebedev authored
    When we rollback a transaction statement, we relink its read trackers
    to a newer story in the history chain, if present (6c990a7b), but we do not
    handle the case when there is no newer story.
    
    If there is an older story in the history chain, we can relink the
    rollbacked story's reader to it, but if the rollbacked story is the
    only one left, we need to retain it, because it stores the reader list
    needed for conflict resolution — such stories are distinguished by the
    rollbacked flag, and there can be no more than one such story located
    strictly at the end of a given history chain (which means a story can be
    fully unlinked from some indexes and present at the end of others).
    
    There are several nuances we need to account for:
    
    Firstly, such rollbacked stories must be impossible to read from an index:
    this is ensured by `memtx_tx_story_is_visible`.
    
    Secondly, rollbacked transactions need to be treated as prepared with
    stories that have `add_psn == del_psn`, so that they are correctly deleted
    during garbage collection.
    
    After this logical change we have the following partially ordered set over
    tuple stories:
    ———————————————————————————————————————————————————————> serialization time
    |- - - - - - - -|— — — — — -|— — — — — |— — — — — — -|— — — — — — — -
    | No more than  | Committed | Prepared | In-progress | One dirty
    | one rollbacked|           |          |             | story in index
    | story         |           |          |             |
    |- - - - - - - -|— — — — — -| — — — — —|— — — — — — -|— — — — — — — —
    
    Closes #7343
    
    NO_DOC=bugfix