1. 03 Nov, 2013 4 commits
  2. 02 Nov, 2013 2 commits
  3. 01 Nov, 2013 1 commit
  4. 31 Oct, 2013 1 commit
    • unknown's avatar
      MDEV-5206: Incorrect slave old-style position in MDEV-4506, parallel replication. · 39df665a
      unknown authored
      In parallel replication, there are two kinds of events which are
      executed in different ways.
      
      Normal events that are part of event groups/transactions are executed
      asynchroneously by being queued for a worker thread.
      
      Other events like format description and rotate and such are executed
      directly in the driver SQL thread.
      
      If the direct execution of the other events were to update the old-style
      position, then the position gets updated too far ahead, before the normal
      events that have been queued for a worker thread have been executed. So
      this patch adds some special cases to prevent such position updates ahead
      of time, and instead queues dummy events for the worker threads, so that
      they will at an appropriate time do the position updates instead.
      
      (Also fix a race in a test case that happened to trigger while running
      tests for this patch).
      39df665a
  5. 30 Oct, 2013 1 commit
    • unknown's avatar
      MDEV-5196: Server hangs or assertion `!thd->wait_for_commit_ptr' fails on... · 9c8da4ed
      unknown authored
      MDEV-5196: Server hangs or assertion `!thd->wait_for_commit_ptr' fails on MASTER_POS_WAIT with slave-parallel-threads > 0
      
      Fix a couple of issues in MDEV-4506, Parallel replication:
      
       - Missing mysql_cond_signal(), which could cause hangs.
      
       - Fix incorrect update of old-style replication position.
      
       - Change assertion to error handling (can trigger on manipulated/
         corrupt binlog).
      9c8da4ed
  6. 29 Oct, 2013 5 commits
    • unknown's avatar
      merge 5.5->10.0-base · f4d5d849
      unknown authored
      f4d5d849
    • unknown's avatar
      Merge 5.3->5.5 · 52dea410
      unknown authored
      52dea410
    • unknown's avatar
      MariaDB made be compiled by gcc 4.8.1 · 5ce11d8b
      unknown authored
        
        There was 2 problems:
        1) coping/moving of the same type (usually casting) as sizeof() (solved in different ways depends on the cause);
        2) using 'const' in SSL_CTX::getVerifyCallback() which return object (not reference) and so copy of the object will be created and 'const' has no sens.
      5ce11d8b
    • unknown's avatar
      MDEV-5195: Race when switching relay log causing crash · f2799c68
      unknown authored
      In parallel replication, when the IO thread switches relay log,
      the SQL thread re-opens the current relaylog and seeks to the
      current position. There was a race that would cause it to
      sometimes seek to the wrong position, causing corruption and
      crash.
      f2799c68
    • timour@askmonty.org's avatar
      MDEV-5104 crash in Item_field::used_tables with broken order by · 883af99e
      timour@askmonty.org authored
      Analysis:
      st_select_lex_unit::prepare() computes can_skip_order_by as TRUE.
      As a result join->prepare() gets called with order == NULL, and
      doesn't do name resolution for the inner ORDER clause. Due to this
      the prepare phase doesn't detect that the query references non-exiting
      function and field.
        
      Later join->optimize() calls update_used_tables() for a non-resolved
      Item_field, which understandably has no Field object. This call results
      in a crash.
      
      Solution:
      Resolve unnecessary ORDER BY clauses to detect if they reference non-exising
      objects. Then remove such clauses from the JOIN object.
      883af99e
  7. 28 Oct, 2013 2 commits
    • unknown's avatar
      MDEV-4506: Parallel replication. · 2fbd1c73
      unknown authored
      MDEV-5189: Error handling in parallel replication.
      
      Fix error handling in parallel worker threads when a query fails:
      
       - Report the error to the error log.
      
       - Return the error back, and set rli->abort_slave.
      
       - Stop executing more events after the error.
      2fbd1c73
    • Sergei Golubchik's avatar
      Don't allow authentication clauses for roles, in particular: · fef41669
      Sergei Golubchik authored
        GRANT ... IDENTIFIED BY [ PASSWORD ] ...
        GRANT ... IDENTIFIED VIA ... [ USING ... ]
        GRANT ... REQUIRE ...
        GRANT ... MAX_xxx ...
        SET PASSWORD FOR ... = ...
      fef41669
  8. 27 Oct, 2013 1 commit
  9. 26 Oct, 2013 2 commits
  10. 25 Oct, 2013 2 commits
    • unknown's avatar
      MDEV-5189: Incorrect parallel apply in parallel replication · 6a38b594
      unknown authored
      Two problems were fixed:
      
      1. When not in GTID mode (master_use_gtid=no), then we must not apply events
         in different domains in parallel (in non-GTID mode we are not capable of
         restarting at different points in different domains).
      
      2. When transactions B and C group commit together, but after and separate
         from A, we can apply B and C in parallel, but both B and C must not start
         until A has committed. Fix sub_id to be globally increasing (not just
         per-domain increasing) so that this wait (which is based on sub_id) can be
         done correctly.
      6a38b594
    • unknown's avatar
      MDEV-4506: Parallel replication. · 80d0dd7b
      unknown authored
      Do not update relay-log.info and master.info on disk after every event
      when using GTID mode:
      
       - relay-log.info and master.info are not crash-safe, and are not used
         when slave restarts in GTID mode (slave connects with GTID position
         instead and immediately rewrites the file with the new, correct
         information found).
      
       - When using GTID and parallel replication, the position in
         relay-log.info is misleading at best and simply wrong at worst.
      
       - When using parallel replication, the fact that every single
         transaction needs to do a write() syscall to the same file is
         likely to become a serious bottleneck.
      
      The files are still written at normal slave stop.
      
      In non-GTID mode, the files are written as normal (this is needed to
      be able to restart after slave crash, even if such restart is then not
      crash-safe, no change).
      80d0dd7b
  11. 24 Oct, 2013 4 commits
  12. 23 Oct, 2013 8 commits
  13. 22 Oct, 2013 1 commit
  14. 21 Oct, 2013 6 commits