Skip to content
Snippets Groups Projects
  1. Jul 26, 2017
  2. Jul 25, 2017
  3. Jul 24, 2017
  4. Jul 21, 2017
  5. Jul 20, 2017
  6. Jul 19, 2017
    • Vladimir Davydov's avatar
      vinyl: use LSN from WAL instead of index_opts->lsn in vylog · 26af611f
      Vladimir Davydov authored
      An index can be dropped and then recreated with the same space/index id.
      To discriminate between different incarnations of the same index during
      recovery, we use index LSN stored in index options, as it is supposed to
      be unique. However, the uniqueness property doesn't always hold:
      
       - If two indexes are created from different fibers, they might receive
         the same LSN.
      
       - If an index is created by inserting a record into _index system space
         directly, without using the public API, as it is the case in case of
         logical backup, its LSN might conflict with the LSN of an existing
         index or a previous incarnation of the same index stored in vylog.
      
      These exceptions can result in unrecoverable errors during local
      recovery, like this one:
      
        F> can't initialize storage: Invalid VYLOG file: Duplicate index id 3
      
      Besides, storing LSN in index options is ugly, because LSN isn't a
      user-defined option - it's a part of the implementation.
      
      To fix this issues, let's use the LSN passed to Index::commitCreate,
      i.e. the actual LSN received by the row that created the index. There's
      one problem though: snapshot rows don't store LSNs. However, it doesn't
      mean we can't find the index in vylog corresponding to a snapshot row:
      we just need to look up the index by space_id/index_id instead of LSN
      and then compare the snapshot LSN with the LSN of the last index
      incarnation stored in vylog - if the latter turns out to be less, then
      we need to load the index, otherwise the index is going to be dropped
      and we need to load a dummy index. For more details, see the comment to
      vy_recovery_load_index().
      
      Another issue that needs a clarification is backward compatibility. The
      thing is the LSN written to the index options lags behind the actual LSN
      assigned to the row that created the index by 1. So to preserve backward
      compatibility, we use LSN from index options for legacy indexes that
      have it, while for indexes created after this patch we don't store LSN
      in index options (set it to 0), neither do we use it on recovery (use
      row LSN instead).
      
      Closes #2536
      26af611f
    • Vladimir Davydov's avatar
      box: generate LSNs for rows received during initial join · 7d67ec8a
      Vladimir Davydov authored
      Currently, 0 is passed to Index::commitCreate as index LSN during
      initial join. To stop using index_opts->lsn for identifying indexes in
      Vinyl, we need a unique LSN. So let's install a dummy journal to assign
      fake unique LSNs for rows received on initial join.
      
      Needed for #2536
      7d67ec8a
    • Vladimir Davydov's avatar
      box: propagate LSN to Index:commitCreate · fd99d3ab
      Vladimir Davydov authored
      So that we could use it instead of index_opts::lsn.
      
      On initial recovery pass the snapshot LSN instead as we don't store LSNs
      in memtx snapshot.
      
      Needed for #2536
      fd99d3ab
    • Vladislav Shpilevoy's avatar
    • Vladislav Shpilevoy's avatar
    • Vladislav Shpilevoy's avatar
      iproto: remove IprotoMsgGuard · 699b14e9
      Vladislav Shpilevoy authored
      699b14e9
    • Vladislav Shpilevoy's avatar
      2ab97c01
    • Vladislav Shpilevoy's avatar
      tuple: introduce tuple_arena_create · a2db8f1d
      Vladislav Shpilevoy authored
      Implement tuple_arena_create method to initialize tuple arena and
      quota. This method further will be used to initialize both
      memtx and vinyl arenas.
      
      Write a test showing the limit of vinyl statements size.
      
      Part of #2569
      a2db8f1d
    • Alexandr Lyapunov's avatar
    • Alexandr Lyapunov's avatar
      Fix memleak in iproto port, clean and optimize the code · bd04983a
      Alexandr Lyapunov authored
      Now if an error happens during the first tuple push from port to
      obuf, the port is not actually destroyed - only the first tuple is
      unreferenced.
      
      I believe that port dump must not free any data at all, then once
      a user creates a port he must take the ownership and destroy it in
      the end of usage. That would simplify the user code, especially C++.
      
      Simplify port_dump function and destroy a port in the code that
      creates the port.
      bd04983a
  7. Jul 18, 2017
  8. Jul 17, 2017
Loading