maria:hf-10.5-10.5.22-MDEV-25163

Last commit made on 2023-09-27
Get this branch:
git clone -b hf-10.5-10.5.22-MDEV-25163 https://git.launchpad.net/maria

Branch merges

Branch information

Name:
hf-10.5-10.5.22-MDEV-25163
Repository:
lp:maria

Recent commits

18b6c01... by Vlad Lesin

MDEV-25163 Rowid filter does not process storage engine error correctly.

The fix is to return 3-state value from Range_rowid_filter::build()
call:
1. The filter was built successfully;
2. The filter was not built, but the error was not fatal, i.e. there is
no need to rollback transaction. For example, if the size of container to
storevrow ids is not enough;
3. The filter was not built because of fatal error, for example,
deadlock or lock wait timeout from storage engine. In this case we
should stop query plan execution and roll back transaction.

Reviewed by: Sergey Petrunya

7e65025... by Oleksandr "Sanja" Byelkin

Merge branch '10.4' into 10.5

2aea938... by Monty <email address hidden>

MDEV-31893 Valgrind reports issues in main.join_cache_notasan

This is also related to
MDEV-31348 Assertion `last_key_entry >= end_pos' failed in virtual bool
           JOIN_CACHE_HASHED::put_record()

Valgrind exposed a problem with the join_cache for hash joins:
=25636== Conditional jump or move depends on uninitialised value(s)
==25636== at 0xA8FF4E: JOIN_CACHE_HASHED::init_hash_table()
          (sql_join_cache.cc:2901)

The reason for this was that avg_record_length contained a random value
if one had used SET optimizer_switch='optimize_join_buffer_size=off'.

This causes either 'random size' memory to be allocated (up to
join_buffer_size) which can increase memory usage or, if avg_record_length
is less than the row size, memory overwrites in thd->mem_root, which is
bad.

Fixed by setting avg_record_length in JOIN_CACHE_HASHED::init()
before it's used.

There is no test case for MDEV-31893 as valgrind of join_cache_notasan
checks that.
I added a test case for MDEV-31348.

8852afe... by Oleksandr "Sanja" Byelkin

Merge branch '10.4' into 10.5

0ede90d... by THIRUNARAYANAN BALATHANDAYUTHAPANI

MDEV-31869 Server aborts when table does drop column

- InnoDB aborts when table is dropping the column. This is
caused by 5f09b53bdb4e973e7c7ec2c53a24c98321223f98 (MDEV-31086).
While iterating the altered table fields, we fail to consider
the dropped columns.

8adb610... by Sergei Golubchik

MDEV-31853 Assertion failure in Column_definition::check_vcol_for_key upon adding FK

when validating vcol's (default, check, etc) in ALTER TABLE
vcol_info->flags are modified in place. This means that if ALTER TABLE
fails for any reason we need to restore them to their original values.

(mroonga was freeing the memory on ::reset() but not on ::close())

10eff9c... by Yuchen Pei <email address hidden>

MDEV-31524 Post-merge fixup

8e8c020... by Oleg Smirnov

MDEV-31743 Server crash in store_length, assertion failure in Type_handler_string_result::sort_length

After MDEV-21580 the truncation of SORT_FIELD::length
  set_if_smaller(sortorder->length, thd->variables.max_sort_length)

became conditional:
  if (is_variable_sized())
    set_if_smaller(length, thd->variables.max_sort_length)

To provide correct functioning of is_variable_sized() SORT_FIELD::type
must be set properly. This commit adds the necessary initialization
of SORT_FIELD::type to JOIN_TAB::remove_duplicates() as it is done
in filesort's sortlength() function.

DBUG_ASSERT is added to sortlength() just in case to prevent
a possible uint32 overflow

61acb43... by Sergei Golubchik

MDEV-31822 ALTER TABLE ENGINE=x started failing instead of producing warning on unsupported TRANSACTIONAL=1

make TRANSACTIONAL table option behave similar to other engine-defined
table options. If the engine doesn't suport it:
* if specified expicitly in CREATE or ALTER - it's ER_UNKNOWN_OPTION
* an error or a warning depending on sql_mode IGNORE_BAD_TABLE_OPTIONS
* in ALTER TABLE from the engine that suppors it to the engine that
  doesn't - silently preserved (no warning)
* it is commented out in SHOW CREATE unless IGNORE_BAD_TABLE_OPTIONS

da09ae0... by Sergei Golubchik

MDEV-18114 Foreign Key Constraint actions don't affect Virtual Column

* invoke check_expression() for all vcol_info's in
  mysql_prepare_create_table() to check for FK CASCADE
* also check for SET NULL and SET DEFAULT
* to check against existing FKs when a vcol is added in ALTER TABLE,
  old FKs must be added to the new_key_list just like other indexes are
* check columns recursively, if vcol1 references vcol2,
  flags of vcol2 must be taken into account
* remove check_table_name_processor(), put that logic under
  check_vcol_func_processor() to avoid walking the tree twice