1. 25 Sep, 2020 1 commit
  2. 24 Sep, 2020 1 commit
  3. 23 Sep, 2020 2 commits
  4. 22 Sep, 2020 14 commits
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · 61df98f9
      Marko Mäkelä authored
      61df98f9
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · d9d9c30b
      Marko Mäkelä authored
      d9d9c30b
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · 9d0ee2dc
      Marko Mäkelä authored
      9d0ee2dc
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · 55e48b77
      Marko Mäkelä authored
      55e48b77
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · fde3d895
      Marko Mäkelä authored
      fde3d895
    • Marko Mäkelä's avatar
      MDEV-22939: Restore an AUTO_INCREMENT check · 78efa109
      Marko Mäkelä authored
      It turns out that we must check for DISCARD TABLESPACE both
      when the table is being rebuilt and when the AUTO_INCREMENT
      value of the table is being added.
      
      This was caught by the test innodb.alter_missing_tablespace.
      Somehow I failed to run all tests. Sorry!
      78efa109
    • Marko Mäkelä's avatar
      MDEV-22939 Server crashes in row_make_new_pathname() · 3eb81136
      Marko Mäkelä authored
      The statement ALTER TABLE...DISCARD TABLESPACE is problematic,
      because its designed purpose is to break the referential integrity
      of the data dictionary and make a table point to nowhere.
      
      ha_innobase::commit_inplace_alter_table(): Check whether the
      table has been discarded. (This is a bit late to check it, right
      before committing the change.) Previously, we performed this check
      only in a specific branch of the function commit_set_autoinc().
      
      Note: We intentionally allow non-rebuilding ALTER TABLE even if
      the tablespace has been discarded, to remain compatible with MySQL.
      (See the various tests with "wl5522" in the name, such as
      innodb.innodb-wl5522.)
      
      The test case would crash starting with 10.3 only, but it does not hurt
      to minimize the code and test difference between 10.2 and 10.3.
      3eb81136
    • Marko Mäkelä's avatar
      Make DISCARD TABLESPACE more robust · e5e83daf
      Marko Mäkelä authored
      dict_load_table_low(): Copy the 'discarded' flag to file_unreadable.
      This allows to avoid a potentially harmful call to dict_stats_init()
      in ha_innobase::open().
      e5e83daf
    • Marko Mäkelä's avatar
      MDEV-23776: Re-apply the fix and make the test more robust · 2af8f712
      Marko Mäkelä authored
      The test that was added in commit e05650e6
      would break a subsequent run of a test encryption.innodb-bad-key-change
      because some pages in the system tablespace would be encrypted with
      a different key.
      
      The failure was repeatable with the following invocation:
      
      ./mtr --no-reorder \
      encryption.create_or_replace,cbc \
      encryption.innodb-bad-key-change,cbc
      
      Because the crash was unrelated to the code changes that we reverted
      in commit eb38b1f7
      we can safely re-apply those fixes.
      2af8f712
    • Jan Lindström's avatar
      98f03e5a
    • Jan Lindström's avatar
      MDEV-21170 : Galera test failure on galera_sr.GCF-1043[A|B] · 98ac2d42
      Jan Lindström authored
      Add error printout when mysql.wsrep_streaming_log lock
      fails. However, tests are very undeterministic and not
      suitable for mtr environment. Thus, they are removed.
      98ac2d42
    • Marko Mäkelä's avatar
      MDEV-23705 Assertion 'table->data_dir_path || !space' · 732cd7fd
      Marko Mäkelä authored
      After DISCARD TABLESPACE, the tablespace of a table will no longer
      exist, and dict_get_and_save_data_dir_path() would invoke
      dict_get_first_path() to read an entry from SYS_DATAFILES.
      For some reason, DISCARD TABLESPACE would not to remove the entry
      from there.
      
      dict_get_and_save_data_dir_path(): If the tablespace has been
      discarded, do not bother trying to read the name.
      
      Side note: The tables SYS_TABLESPACES and SYS_DATAFILES are
      redundant and subject to removal in MDEV-22343.
      732cd7fd
    • Marko Mäkelä's avatar
      Revert "MDEV-23776 Test encryption.create_or_replace fails with a warning" · eb38b1f7
      Marko Mäkelä authored
      This reverts commit e33f7b6f.
      The change seems to have introduced intermittent failures of the test
      encryption.innodb-bad-key-change on many platforms.
      
      The failure that we were trying to address was not reproduced on 10.2.
      It could be related to commit a7dd7c89
      (MDEV-23651) or de942c9f (MDEV-15983)
      or other changes that reduced contention on fil_system.mutex in 10.3.
      
      The fix that we are hereby reverting from 10.2 seems to work fine
      on 10.3 and 10.4.
      eb38b1f7
    • Daniel Black's avatar
      systemd: mariadb@bootstrap - clear ExecStartPre and ExecStartPost · 4c192279
      Daniel Black authored
      This is just to make sure no ExecStartPre/Post actions from the
      multi-instance MariaDB service definition are executed
      when a user attempts to start mariadb@bootstrap.
      
      Fixes: 3723c70a
      4c192279
  5. 21 Sep, 2020 13 commits
  6. 18 Sep, 2020 2 commits
  7. 17 Sep, 2020 4 commits
  8. 16 Sep, 2020 2 commits
    • Jan Lindström's avatar
      MDEV-21655 : galera.galera_wan_restart_ist MTR fails sporadically: WSREP did... · 96426dac
      Jan Lindström authored
      MDEV-21655 : galera.galera_wan_restart_ist MTR fails sporadically: WSREP did not transition to state READY
      
      Replace sleeps with proper wait_conditions to wait correct
      cluster configuration.
      96426dac
    • 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
  9. 14 Sep, 2020 1 commit