1. 20 Oct, 2020 3 commits
    • Anel Husakovic's avatar
      Updated mtr help · 0627c4ae
      Anel Husakovic authored
      - Updated combination example to use `innodb_plugin`
      ```
      $ ./mysql-test/mtr rpl.rpl_invoked_features # no rpl.rpl_invoked_features,mix,xtradb_plugin
      
      worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
      rpl.rpl_invoked_features 'innodb_plugin,mix' [ pass ]    904
      rpl.rpl_invoked_features 'mix,xtradb'    [ pass ]   1707
      rpl.rpl_invoked_features 'innodb_plugin,row' [ pass ]    927
      rpl.rpl_invoked_features 'row,xtradb'    [ pass ]    828
      rpl.rpl_invoked_features 'innodb_plugin,stmt' [ pass ]    855
      rpl.rpl_invoked_features 'stmt,xtradb'   [ pass ]    952
      --------------------------------------------------------------------------
      ```
      - `gdb` option can take optional gdb arguments (good documentation in
      KB)
      0627c4ae
    • Rucha Deodhar's avatar
      MDEV-5628: Assertion `! is_set()' or `!is_set() || (m_status == DA_OK_BULK && · 9fca6645
      Rucha Deodhar authored
      is_bulk_op())' fails on UPDATE on a partitioned table with subquery
      (MySQL:71630)
      
      Analysis and fix: Error is not checked. So correct error state is not returned.
      Fix: Check for error and return the error state.
      9fca6645
    • Rucha Deodhar's avatar
      MDEV-17729: Assertion `! is_set() || m_can_overwrite_status' failed in · d36cd5f0
      Rucha Deodhar authored
      Diagnostics_area::set_error_status
      
      Analysis: When strict mode is enabled, all warnings are converted to errors
      including those which do not occur because of bad data.
      Fix: Query should not be aborted when we have warning because limit to
      examine rows was reached because it doesn't happen due to bad data.
      So thd->abort_on_warning should be false.
      d36cd5f0
  2. 15 Oct, 2020 1 commit
  3. 14 Oct, 2020 1 commit
  4. 08 Oct, 2020 1 commit
  5. 07 Oct, 2020 5 commits
    • Daniel Black's avatar
      MDEV-4851: (tests) log tables modifiable on log_output!=TABLE · 874942a0
      Daniel Black authored
      Test we can ALTER log tables directly when not being written
      to.
      
      This removes the contraint in the rpl_mysql_upgrade.test such
      that we can run mysql_upgrade --write-binlog all the way
      through to a replica. We test this in the replication scenario
      where the mysql.{slow,general}_log tables aren't being
      written to.
      
      Reviewers: Vicențiu Ciorbaru, Anel Husakovic
      874942a0
    • Nisha Gopalakrishnan's avatar
      MDEV-4851: BUG#11763447: 'YOU CANNOT 'ALTER' A LOG TABLE IF LOGGING IS ENABLED' · 00c44fb1
      Nisha Gopalakrishnan authored
                     EVEN IF I LOG TO FILE.
      
      Analysis:
      ----------
      
      MYSQL_UPGRADE of the master breaks the replication when
      the query logging is enabled with FILE/NONE 'log-output'
      option on the slave.
      
      mysql_upgrade modifies the 'general_log' and 'slow_log'
      tables after the logging is disabled as below:
      
      SET @old_log_state = @@global.general_log;
      SET GLOBAL general_log = 'OFF';
      ALTER TABLE general_log
      MODIFY event_time TIMESTAMP NOT NULL,
      ( .... );
      SET GLOBAL general_log = @old_log_state;
      
      and
      
      SET @old_log_state = @@global.slow_query_log;
      SET GLOBAL slow_query_log = 'OFF';
      ALTER TABLE slow_log
      MODIFY start_time TIMESTAMP NOT NULL,
      ( .... );
      SET GLOBAL slow_query_log = @old_log_state;
      
      In the binary log, only the ALTER statements are logged
      but not the SET statements which turns ON/OFF the logging.
      So when the slave replays the binary log,the ALTER of LOG
      tables throws an error since the logging is enabled. Also
      the 'log-output' option is not checked to determine
      whether to allow/disallow the ALTER operation.
      
      Fix:
      ----
      The 'log-output' option is included in the check while
      determining whether the query logging happens using the
      log tables.
      
      Picked from mysql respository at 0daaf8aecd8f84ff1fb400029139222ea1f0d812
      00c44fb1
    • Sergei Golubchik's avatar
      Merge tag 'mariadb-10.1.47' into 10.1 · 83bd8ebf
      Sergei Golubchik authored
      83bd8ebf
    • Daniel Bartholomew's avatar
      bump the VERSION · 1a850225
      Daniel Bartholomew authored
      1a850225
    • Andrei Elkin's avatar
      MDEV-23832 Crash at startup in Log_event::read_log_event · 65c632cb
      Andrei Elkin authored
      The crash was caused by improper raising of an error or replication checksum
      verification at time of the server initialization. As there is no THD object
      associated with the main initializing thread yet the error text should be
      assigned with calling a respective macro that is aware of that possibility.
      
      Fixed accordingly.
      
      [At merging to 10.4 the new test result file needs
       +# restart: --master_verify_checksum=ON --debug_dbug=+d,corrupt_read_log_event_char
      that mtr run will hint on.]
      65c632cb
  6. 05 Oct, 2020 2 commits
  7. 02 Oct, 2020 1 commit
  8. 01 Oct, 2020 1 commit
  9. 30 Sep, 2020 1 commit
  10. 29 Sep, 2020 1 commit
  11. 28 Sep, 2020 2 commits
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-22277 LeakSanitizer: detected memory leaks in mem_heap_create_block_func... · fdb3c64e
      Thirunarayanan Balathandayuthapani authored
      MDEV-22277 LeakSanitizer: detected memory leaks in mem_heap_create_block_func after attempt to create foreign key
      
      - During online DDL, prepare phase error handler fails to remove
      the memory allocated for newly created foreign keys.
      fdb3c64e
    • Sujatha's avatar
      MDEV-22330: mysqlbinlog stops with an error Don't know how to handle column... · 15cd9195
      Sujatha authored
      MDEV-22330: mysqlbinlog stops with an error Don't know how to handle column type: 255 meta: 4 (0004)
      
      Analysis:
      ========
      "mysqlbinlog -v" option will reconstruct row events and display them as
      commented SQL statements. If this option is given twice, the output includes
      comments to indicate column data types and some metadata.
      `log_event_print_value` is the function reponsible for printing values and
      their types. This function doesn't handle GEOMETRY type. Hence the above error
      gets printed.
      
      Fix:
      ===
      Add support for GEOMETRY datatype.
      15cd9195
  12. 25 Sep, 2020 1 commit
  13. 24 Sep, 2020 1 commit
  14. 23 Sep, 2020 3 commits
  15. 22 Sep, 2020 1 commit
  16. 20 Sep, 2020 9 commits
  17. 16 Sep, 2020 1 commit
    • Sujatha's avatar
      MDEV-21839: Handle crazy offset to SHOW BINLOG EVENTS · 873cc1e7
      Sujatha authored
      Problem:
      =======
      SHOW BINLOG EVENTS FROM <"random"-pos> caused a variety of failures as
      reported in MDEV-18046. They are fixed but that approach is not future-proof
      as well as is not optimal to create extra check for being constructed event
      parameters.
      
      Analysis:
      =========
      "show binlog events from <pos>" code considers the user given position as a
      valid event start position. The code starts reading data from this event start
      position onwards and tries to map it to a set of known events. Each event has
      a specific event structure and asserts have been added to ensure that, read
      event data, satisfies the event specific requirements. When a random position
      is supplied to "show binlog events command" the event structure specific
      checks will fail and they result in assert.
      
      For example: https://jira.mariadb.org/browse/MDEV-18046
      In the bug description user executes CREATE TABLE/INSERT and ALTER SQL
      commands.
      
      When a crazy offset like "SHOW BINLOG EVENTS FROM 365" is provided code
      assumes offset 365 as valid event begin and proceeds to EVENT_LEN_OFFSET reads
      some random length and comes up with a crazy event which didn't exits in the
      binary log. In this quoted example scenario, event read at offset 365 is
      considered as "Update_rows_log_event", which is not present in binary log.
      Since this is a random event its validation fails and code results in
      assert/segmentation fault, as shown below.
      
      mysqld: /data/src/10.4/sql/log_event.cc:10863: Rows_log_event::Rows_log_event(
          const char*, uint, const Format_description_log_event*):
          Assertion `var_header_len >= 2' failed.
          181220 15:27:02 [ERROR] mysqld got signal 6 ;
      #7  0x00007fa0d96abee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      #8  0x000055e744ef82de in Rows_log_event::Rows_log_event (this=0x7fa05800d390,
          buf=0x7fa05800d080 "", event_len=254, description_event=0x7fa058006d60) at
      /data/src/10.4/sql/log_event.cc:10863
      #9  0x000055e744f00cf8 in Update_rows_log_event::Update_rows_log_event
      
      Since we are reading random data repeating the same command SHOW BINLOG EVENTS
      FROM 365 produces different types of crashes with different events. MDEV-18046
      reported 10 such crashes.
      
      In order to avoid such scenarios user provided starting offset needs to be
      validated for its correctness. Best way of doing this is to make use of
      checksums if they are available. MDEV-18046 fix introduced the checksum based
      validation.
      
      The issue still remains in cases where binlog checksums are disabled. Please
      find the following bug reports.
      
      MDEV-22473: binlog.binlog_show_binlog_event_random_pos failed in buildbot,
                  server crashed in read_log_event
      MDEV-22455: Server crashes in Table_map_log_event,
                  binlog.binlog_invalid_read_in_rotate failed in buildbot
      
      Fix:
      ====
      When binlog checksum is disabled, perform scan(via reading event by event), to
      validate the requested FROM <pos> offset. Starting from offset 4 read the
      event_length of next_event in the binary log. Using the next_event length
      advance current offset to point to next event. Repeat this process till the
      current offset is less than or equal to crazy offset. If current offset is
      higher than crazy offset provide appropriate invalid input offset error.
      873cc1e7
  18. 14 Sep, 2020 1 commit
  19. 11 Sep, 2020 2 commits
  20. 07 Sep, 2020 2 commits
    • Sujatha's avatar
      MDEV-9501: rpl.rpl_binlog_index, rpl.rpl_gtid_crash, rpl.rpl_stm_multi_query... · a8f6bbb7
      Sujatha authored
      MDEV-9501: rpl.rpl_binlog_index, rpl.rpl_gtid_crash, rpl.rpl_stm_multi_query fail sporadically in buildbot with Master command COM_REGISTER_SLAVE failed
      
      Analysis:
      ========
      Slave server will send COM_REGISTER_SLAVE command at the time of establishing
      a connection to master. If master is down, then the command will fail and
      COM_REGISTER_SLAVE failed warning is reported.
      
      'rpl_binlog_index.test' shutsdown the master and it relocates binary logs to a
      new location and attempts to start master by pointing 'log-bin' to new
      location. During this process the slave threads are active. IO thread actively
      checks for the presence of master when it finds that the connection is lost it
      attempts a reconnect, as master is down COM_REGISTER_SLAVE command fails.
      
      As part of fix, stop the slave threads and then shutdown the master and do the
      binlog relocation. Once master is restarted start the slave threads and sync
      them with the master. In test binary logs and index files on master are
      relocated to /tmpdir but during master restart only --log-bin option is
      provided, this is incorrect. Even --log-bin-index also should be pointed to
      /tmpdir otherwise upon master server restart two index files will be created.
      One master-bin.index in /tmpdir and a new master-bin.index as per log_basename
      in datadir. Due to this slave will fail to connect to master.
      
      'rpl_gtid_crash.test' tests following scenario "crashing master, causing slave
      IO thread to reconnect while SQL thread is running". When IO thread tries to
      connect to crashed master on slow platforms COM_REGISTER_SLAVE command fails.
      This is expected hence the warning should be added to suppression list.
      a8f6bbb7
    • Kentoku SHIBA's avatar
      MDEV-7098 spider/bg.spider_fixes failed in buildbot with safe_mutex: Trying to... · 420c4dcc
      Kentoku SHIBA authored
      MDEV-7098 spider/bg.spider_fixes failed in buildbot with safe_mutex: Trying to unlock mutex conn->mta_conn_mutex that wasn't locked at storage/spider/spd_db_conn.cc, line 671
      420c4dcc