1. 13 May, 2021 3 commits
    • Sergei Petrunia's avatar
      MDEV-25154: JSON_TABLE: Queries involving ordinality columns are unsafe ... · 4547c6f2
      Sergei Petrunia authored
      Mark the JSON_TABLE function as SBR-unsafe.
      It is not unsafe for the current implementation. But we still mark it as such
      in order to be future-proof and keep it possible to change JSON data
      representation in the future.
      4547c6f2
    • Marko Mäkelä's avatar
      fixup e3b33842: wsrep test results · 916c28c9
      Marko Mäkelä authored
      916c28c9
    • Sujatha's avatar
      MDEV-25502: rpl.rpl_perfschema_applier_status_by_worker failed in bb with: Test assertion failed · fe945067
      Sujatha authored
      Problem:
      =======
      Test fails with 3 different symptoms
      connection slave;
      Assertion text: 'Last_Seen_Transaction should show .'
      Assertion condition: '"0-1-1" = ""'
      Assertion condition, interpolated: '"0-1-1" = ""'
      Assertion result: '0'
      
      connection slave;
      Assertion text: 'Value returned by SSS and PS table for Last_Error_Number
                       should be same.'
      Assertion condition: '"1146" = "0"'
      Assertion condition, interpolated: '"1146" = "0"'
      Assertion result: '0'
      
      connection slave;
      Assertion text: 'Value returned by PS table for worker_idle_time should be
                      >= 1'
      Assertion condition: '"0" >= "1"'
      Assertion condition, interpolated: '"0" >= "1"'
      Assertion result: '0'
      
      Fix1:
      ====
      Performance schema table's Last_Seen_Transaction is compared with 'SELECT
      gtid_slave_pos'. Since DDLs are not transactional changes to user table and
      gtid_slave_pos table are not guaranteed to be synchronous. To fix the
      issue Gtid_IO_Pos value from SHOW SLAVE STATUS command will be used to
      verify the correctness of Performance schema specific
      Last_Seen_Transaction.
      
      Fix2:
      ====
      On error worker thread information is stored as part of backup pool. Access
      to this backup pool should be protected by 'LOCK_rpl_thread_pool' mutex so
      that simultaneous START SLAVE cannot destroy the backup pool, while it is
      being queried by performance schema.
      
      Fix3:
      ====
      When a worker is waiting for events if performance schema table is queried,
      at present it just returns the difference between current_time and
      start_time.  This is incorrect. It should be worker_idle_time +
      (current_time - start_time).
      
      For example a worker thread was idle for 10 seconds and then it got events
      to process. Upon completion it goes to idle state, now if the pfs table is
      queried it should return current_idle time  + worker_idle_time.
      fe945067
  2. 12 May, 2021 3 commits
    • Nikita Malyavin's avatar
      tztime_to_sql: quote `Offset` field · e3b33842
      Nikita Malyavin authored
      e3b33842
    • Kentoku SHIBA's avatar
      Fix the following valgrind error on Spider · 982290fe
      Kentoku SHIBA authored
      ==22532== Conditional jump or move depends on uninitialised value(s)
      ==22532==    at 0x9EEDFA: String::append(char const*, unsigned long, charset_info_st const*) (sql_string.cc:587)
      ==22532==    by 0x17C12BA7: spider_string::append(char const*, unsigned int, charset_info_st const*) (spd_malloc.cc:913)
      ==22532==    by 0x17C68BD0: spider_db_mysql_util::append_column_value(ha_spider*, spider_string*, Field*, unsigned char const*, charset_info_st const*) (spd_db_mysql.cc:4573)
      ==22532==    by 0x17B7D298: spider_db_append_key_where_internal(spider_string*, spider_string*, spider_string*, st_key_range const*, st_key_range const*, ha_spider*, bool, unsigned long, unsigned int) (spd_db_conn.cc:1978)
      ==22532==    by 0x17C81A7C: spider_mbase_handler::append_key_where(spider_string*, spider_string*, spider_string*, st_key_range const*, st_key_range const*, unsigned long, bool) (spd_db_mysql.cc:11146)
      ==22532==    by 0x17C819B7: spider_mbase_handler::append_key_where_part(st_key_range const*, st_key_range const*, unsigned long) (spd_db_mysql.cc:11130)
      ==22532==    by 0x17C4B0F0: ha_spider::append_key_where_sql_part(st_key_range const*, st_key_range const*, unsigned long) (ha_spider.cc:15012)
      ==22532==    by 0x17B7FC8F: spider_db_append_key_where(st_key_range const*, st_key_range const*, ha_spider*) (spd_db_conn.cc:2707)
      ==22532==    by 0x17C28DF6: ha_spider::multi_range_read_next_first(void**) (ha_spider.cc:4559)
      ==22532==    by 0x17C2E0F5: ha_spider::multi_range_read_next(void**) (ha_spider.cc:5879)
      ==22532==    by 0xE27019: QUICK_RANGE_SELECT::get_next() (opt_range.cc:12647)
      
      Conflicts:
      	storage/spider/spd_malloc.cc
      982290fe
    • Marko Mäkelä's avatar
      Merge 10.5 into 10.6 · 370b310b
      Marko Mäkelä authored
      370b310b
  3. 11 May, 2021 4 commits
  4. 10 May, 2021 8 commits
  5. 09 May, 2021 6 commits
  6. 08 May, 2021 5 commits
  7. 07 May, 2021 10 commits
  8. 06 May, 2021 1 commit
    • Marko Mäkelä's avatar
      MDEV-25506 (2 of 3): Kill during DDL leaves orphan .ibd file · 2ceadb39
      Marko Mäkelä authored
      dict_drop_index_tree(): Even if SYS_INDEXES.PAGE contains the
      special value FIL_NULL, the tablespace identified by SYS_INDEXES.SPACE
      may exist and may need to be dropped. This would definitely be the case
      if the server had been killed right after a FILE_CREATE record was
      persistently written during CREATE TABLE, but before the transaction
      was committed.
      
      btr_free_if_exists(): Simplify the interface, to avoid repeated
      tablespace lookup.
      
      One more scenario is known to be broken: If the server is killed
      during DROP TABLE (or table-rebuilding ALTER TABLE) right after a
      FILE_DELETE record has been persistently written but before the
      file was deleted, then we could end up recovering no tablespace
      at all, and failing to delete the file, in either of fil_name_process()
      or dict_drop_index_tree().
      
      Thanks to Elena Stepanova for providing "rr replay" and data directories
      of these scenarios.
      2ceadb39