maria:10.2-MDEV-24026

Last commit made on 2020-10-27
Get this branch:
git clone -b 10.2-MDEV-24026 https://git.launchpad.net/maria

Branch merges

Branch information

Name:
10.2-MDEV-24026
Repository:
lp:maria

Recent commits

66de5e2... by Vlad Lesin

MDEV-24026: InnoDB: Failing assertion: os_total_large_mem_allocated >= size upon incremental backup

Preliminary fix without test case.

8761571... by Alexey Botchkov

MDEV-22524 SIGABRT in safe_mutex_unlock with
session_track_system_variables and max_relay_log_size.

lock LOCK_global_system_variables around the get_one_variable() call
in the Session_sysvars_tracker::store_variable().

bc540b8... by THIRUNARAYANAN BALATHANDAYUTHAPANI

MDEV-23693 Failing assertion: my_atomic_load32_explicit(&lock->lock_word, MY_MEMORY_ORDER_RELAXED) == X_LOCK_DECR

InnoDB frees the block lock during buffer pool shrinking when other
thread is yet to release the block lock. While shrinking the
buffer pool, InnoDB allows the page to be freed unless it is buffer
fixed. In some cases, InnoDB releases the latch after unfixing the
block.

Fix:
====
- InnoDB should unfix the block after releases the latch.

- Add more assertion to check buffer fix while accessing the page.

- Introduced block_hint structure to store buf_block_t pointer
and allow accessing the buf_block_t pointer only by passing a
functor. It returns original buf_block_t* pointer if it is valid
or nullptr if the pointer become stale.

- Replace buf_block_is_uncompressed() with
buf_pool_t::is_block_pointer()

This change is motivated by a change in mysql-5.7.32:
mysql/mysql-server@46e60de444a8fbd876cc6778a7e64a1d3426a48d
Bug #31036301 ASSERTION FAILURE: SYNC0RW.IC:429:LOCK->LOCK_WORD

6a614d6... by mkaruza <email address hidden>

MDEV-22707: galera got stuck after flush tables

Deadlock is possible between applier thread and local committing thread with active FLUSH TABLE.
Applier thread should skip table share checks and locks when opening table.

Reviewed-by: Jan Lindström <email address hidden>

1ff8588... by Sachin Agarwal <email address hidden>

Bug #31228694 FTS QUERY WITH LIMIT HIT AN ASSERT

Problem:
1. The server terminates abnormally when phrase search doesn't
filter out doc_ids correctly. This problem has been fixed in bug
2
. Wrong query result: It's a regression from the bug #22709692 fix.
This fix optimize full-text search query with limit clause.
when FTS expression involves only union operation, we fetch only
number of doc_ids specified with the limit clause.
Fulltext phrase search is not an union operation and we consider
phrase search with plugin parser a union operation.
In phrase search with limit clause, we fetch limited doc_ids for
each token and if any of the selected doc_id does not contain all
tokens in correct order then we do not include that row_id in the
result set.
Therefore phrase search gets fewer number of rows than the qualified
rows exist in the table.

Fix:
Added a condition that phrase search with plugin parser is not a
union operation.

RB: 24925
Reviewed by : Annamalai Gurusami <email address hidden>

This is a cherry-pick of
mysql/mysql-server@5549920b7a33ef33034461d973a9ecb17ce49799
without a test case, because the test case depends on an n-gram
tokenizer that will be missing from MariaDB until MDEV-10267 is added.

e391417... by Sachin Agarwal <email address hidden>

Bug #30933728 INNODB FTS PHRASE SEARCH HIT AN ASSERT

Problem:
In Full-text phrase search, we filter out row that do not contain
all the tokens in the phrase.
If we do not filter out doc_id that doesn't appear in all the
token's doc_id lists then we hit an assert.

Fix:
if any of the token has last doc_id equal to ith doc_id of the first
token doc_id list then filter out rest of the higher doc_ids.

RB: 24909
Reviewed by : Annamalai Gurusami <email address hidden>

This is a cherry-pick of
mysql/mysql-server@5aa075277dfe84a17a0331c57a6fe9b91dafb4cf
but without a test case, because the test case depends on an n-gram
tokenizer that will be missing from MariaDB until MDEV-10267 is added.

784473b... by Oleksandr "Sanja" Byelkin

Merge remote-tracking branch 'connect/10.2' into 10.2

2fdc503... by Sergei Golubchik

remove disable_abort_on_error from precedence.test

was left over from testing

3ba8f61... by THIRUNARAYANAN BALATHANDAYUTHAPANI

MDEV-23370 innodb_fts.innodb_fts_misc failed in buildbot, server crashed in dict_table_autoinc_destroy

This issue is caused by MDEV-22456 ad6171b91cac33e70bb28fa6865488b2c65e858c. Fix involves the backported version of 10.4 patch
MDEV-22778 5f2628d1eea21d9732f582b77782b072e5e04014 and few parts of
MDEV-17441 (e9a5f288f21c15ec6b4d2dd3d654a320904bb1bf).

dict_table_t::stats_latch_created: Removed

dict_table_t::stats_latch: make value member and always lock it for
simplicity even for stats cloned table.

zip_pad_info_t::mutex_created: Removed

zip_pad_info_t::mutex: make member value instead of pointer

os0once.h: Removed

dict_table_remove_from_cache_low(): Ensure that fts_free() is always
called, even if dict_mem_table_free() is deferred until
btr_search_lazy_free().

InnoDB would always zip_pad_info_t::mutex and
dict_table_t::autoinc_mutex, even for tables are not in
ROW_FORMAT=COMPRESSED nor include any AUTO_INCREMENT column.

987df9b... by Marko Mäkelä

MDEV-23720 Change innodb_log_optimize_ddl=OFF by default

MariaDB 10.2.2 inherited from MySQL 5.7 a perceived optimization
of ALTER TABLE, which skips the writing of redo log records.
In MDEV-16809 we introduced a parameter that allows the redo log to
be written, so that Mariabackup would not be impacted, but we kept
the MySQL 5.7 behaviour enabled by default (innodb_log_optimize_ddl=ON).

As noted in MDEV-19747 (Deprecate and ignore innodb_log_optimize_ddl,
implemented in MariaDB 10.5.1), omitting the redo log writes can
actually reduce performance, because we will have to wait for the data
pages to be written out. When the redo log file is configured to be
large enough, it actually can be much faster to write the redo log and
avoid the extra page flushing.

When the redo log is omitted (innodb_log_optimize_ddl=ON), also
Mariabackup may have to perform a lot of extra work, to re-copy the
entire data file if it is possible that any log was omitted during
the backup.

Starting with MariaDB 10.5.1, the parameter innodb_log_optimize_ddl
is deprecated and ignored. We hereby deprecate (but will not ignore)
the parameter in earlier versions as well.