1. 06 Aug, 2017 1 commit
  2. 04 Aug, 2017 1 commit
  3. 03 Aug, 2017 3 commits
  4. 28 Jul, 2017 2 commits
  5. 21 Jul, 2017 3 commits
  6. 17 Jul, 2017 2 commits
    • Alexander Kuleshov's avatar
      update .gitignore · bc75c57c
      Alexander Kuleshov authored
      during build on 10.2 following files are generated:
      
        * scripts/galera_new_cluster
        * scripts/galera_recovery
        * support-files/mariadb.service
        * support-files/mariadb.pp
      
      and they are untracked for git. Let's add them to .gitignore
      bc75c57c
    • Vladislav Vaintroub's avatar
      MDEV-13332 mariabackup from 10.2.x crashes with --ftwrl-* options · 013595f5
      Vladislav Vaintroub authored
      Fixed null pointer dereference in parsing "show full processlist" output
      with atoi().
      
      Some  Innodb background thread has NULL in 'Time' column,
      thus  backup would crash with when atoi is applied to null pointer.
      013595f5
  7. 15 Jul, 2017 1 commit
  8. 13 Jul, 2017 4 commits
  9. 12 Jul, 2017 3 commits
  10. 11 Jul, 2017 1 commit
  11. 09 Jul, 2017 6 commits
  12. 08 Jul, 2017 1 commit
  13. 07 Jul, 2017 5 commits
    • Sergei Golubchik's avatar
      compilation warning · 5789934f
      Sergei Golubchik authored
      5789934f
    • Marko Mäkelä's avatar
      MDEV-13267 At startup with crash recovery: mtr_t::commit_checkpoint(lsn_t,... · 42f657cd
      Marko Mäkelä authored
      MDEV-13267 At startup with crash recovery: mtr_t::commit_checkpoint(lsn_t, bool): Assertion `!recv_no_log_write' failed
      
      This is a bogus debug assertion failure that should be possible
      starting with MariaDB 10.2.2 (which merged WL#7142 via MySQL 5.7.9).
      
      While generating page-change redo log records is strictly out of the
      question during tat certain parts of crash recovery, the
      fil_names_clear() is only emitting informational MLOG_FILE_NAME
      and MLOG_CHECKPOINT records to guarantee that if the server is killed
      during or soon after the crash recovery, subsequent crash recovery
      will be possible.
      
      The metadata buffer that fil_names_clear() is flushing to the redo log
      is being filled by recv_init_crash_recovery_spaces(), right before
      starting to apply redo log, by invoking fil_names_dirty() on every
      discovered tablespace for which there are changes to apply.
      
      When it comes to Mariabackup (xtrabackup --prepare), it is strictly out
      of the question to generate any redo log whatsoever, because that could
      break the restore of incremental backups by causing LSN deviation.
      So, the fil_names_dirty() call must be skipped when restoring backups.
      
      recv_recovery_from_checkpoint_start(): Do not invoke fil_names_clear()
      when restoring a backup.
      
      mtr_t::commit_checkpoint(): Remove the failing assertion. The only
      caller is fil_names_clear(), and it must be called by
      recv_recovery_from_checkpoint_start() for normal server startup to be
      crash-safe. The debug assertion in mtr_t::commit() will still
      catch rogue redo log writes.
      42f657cd
    • Sergei Golubchik's avatar
      Merge branch '10.0' into 10.1 · 9e11e055
      Sergei Golubchik authored
      9e11e055
    • Marko Mäkelä's avatar
      f20693c2
    • Daniel Black's avatar
      travis: Debian build - minimise packages, enable ccache · 3b862aaa
      Daniel Black authored
      Even disabling the ccache on the Debian build didn't always prevent
      the Travis build running out of space.
      
      As an alternative strategy, the number of alternative compilers has been
      reduced to save space. This additional space has been partially reused
      by the ccache.
      
      Debian build specific packages have been removed from other builds.
      3b862aaa
  14. 06 Jul, 2017 7 commits