Console View

Categories: connectors experimental galera main

Legend:

Passed

Failed

Warnings

Failed Again

Running

Exception

Offline

No data

connectors

experimental

galera

main

fbb2cb5be24a...

fbb2cb5be24a719b260eeb114b7af49a44206de2

Sergei Golubchik

serg@mariadb.org

tentative post-merge to keep commit d228f237f27

eba938f9eb61...

eba938f9eb615ba1d2c1277e7cbebe0079582083

Aleksey Midenkov

midenok@gmail.com

MDEV-37275 Cannot remove default value of NOT NULL column

Run-time has semantics duplication in unireg_check, default_value and
flags, so all three must be in sync before FRM creation. Special
unireg_check values for temporal field types was introduced by
32b28f92980 WL#1266 "Separate auto-set logic from TIMESTAMP type."

eba285f2a21f...

eba285f2a21fc50268d726ecee4f4ab2e6846374

Sergei Golubchik

serg@mariadb.org

MDEV-36787 Error 153: No savepoint with that name upon ROLLBACK TO SAVEPOINT, assertion failure

InnoDB was rolling back a transaction internally, while
the server thought the transaction stayed open.

this was fixed
in 10.11 by 387fe5ecc3a to rollback the transaction in the server
and in 12.3 by d228f237f27 to not rollback in InnoDB

let's keep 12.3 behavior, update test results to match.
but combine two nearly indentical test cases into one.

e52f7ff07424...

e52f7ff074246e1027f2433c3016c199ead0ec64

Dave Gosselin

dave.gosselin@mariadb.com

MDEV-38747: ASAN errors in Optimizer_hint_parser::Identifier::to_ident_cli

Summary:
A trigger specifying a hint where the hint has a query block name will cause
an ASAN failure because hint resolution occurs after query parsing, not
during query parsing. The trigger execution logic uses a stack-local
string to hold the query and hint text during parsing. In trigger execution,
query parsing and query execution happen in different function contexts, so
the query string used during parsing goes out of scope, freeing its memory.
But as hint resolution occurs after parsing is complete (and hints merely
point into the query string, they don't copy from it), the hints refer into
a deallocated query string upon hint resolution.

Details:
Prior to the commit introducing this bug, hint resolution was done via a call
to `LEX::resolve_optimizer_hints_in_last_select` when parsing the
`query_specification:` grammar rule. This meant that any string containing
the query (and hints) was in scope for the entire lifetime of query parsing
and hint resolution.

In the patch introducing this bug, `resolve_optimizer_hints_in_last_select`
was changed to merely cache hints for resolution during query execution.
Upon query execution, `mysql_execute_command` calls `LEX::resolve_optimizer_hints`
to resolve hints and this is after query parsing. `sp_lex_instr::parse_expr`
reparses the query associated with a trigger and does so using a stack-local
String variable to hold the query text. `sp_lex_instr::parse_expr` returns after
query parsing completes but before hint resolution begins. Since
the string holding the query was stack-local in `sp_lex_instr::parse_expr` and
destroyed when the method returned, the query string (and hints with it) were
deallocated, leading to the ASAN failure on hint resolution. When executing
the trigger, `sp_instr_stmt::exec_core` calls `mysql_execute_command` which
calls `LEX::resolve_optimizer_hints` to complete hint resolution but the query
string that the hints depends on no longer exists at this point.

As noted, the stack-local `query_string` variable in `sp_lex_inst::parse_expr`
goes out-of-scope and is freed when the `sp_lex_instr::parse_expr` returns. In
contrast, in the general case, when a `COM_QUERY` is processed during
`dispatch_command`, the query string lives on the `THD` for the lifetime of
the query independent of some particular function's scope.

For triggers, the necessary lifetime of that query string needs to be as long
as `sp_lex_keeper::validate_lex_and_exec_core` which covers both the query
string parsing via `sp_lex_instr::parse_expr` and the procedure's execution
during `reset_lex_and_exec_core`. Consequently, this patch lifts the
`query_string` buffer up out of `parse_expr` and passes a pointer to it into
`parse_expr` to guarantee the query string's lifetime across parsing and
execution, for hint resolution.

QB_NAME is not the only affected hint kind; hints with some query block
identifier text for the query block, like
```
NO_MERGE(`@select#1`)
```
will also cause the crash while `NO_MERGE()` will not.

dc28140c89f6...

dc28140c89f6a64a055ef52deed420c53f4a9bea

bsrikanth-mariadb

srikanth.bondalapati@mariadb.com

MDEV-31255: Crash with fulltext search subquery in explain delete/update

ft_handler isn't getting initialized for subqueries inside explain
delete/update queries. However, ft_handler is accessed inside ha_ft_read(),
and is the reason for NULL pointer exception.
This is not the case with non-explain delete/update queries, as
well as explain/non-explain select queries.

Follow the approach the SELECT statements are using in
JOIN::optimize_constant_subqueries(): remove SELECT_DESCRIBE
flag when invoking optimization of constant subqueries.

Single-table UPDATE/DELETEs have SELECT_LEX but don't have JOIN.
So, we make optimize_constant_subqueries() not to be a member
of JOIN class, and instead move it to SELECT_LEX, and then
invoke it from single-table UPDATE/DELETE as well as for SELECT queries.

d5fb3dccd72d...

d5fb3dccd72d816c7181a069b91eedb3c76b2715

Michael Widenius

monty@mariadb.org

MDEV-19683 Add support for Oracle TO_DATE()

Syntax:
TO_DATE(string_expression [DEFAULT string_expression ON CONVERSION ERROR],
format_string [,NLS_FORMAT_STRING])
The format_string has the same format elements as TO_CHAR(), except a
few elements that are not supported/usable for TO_DATE().
TO_DATE() returns a datetime or date value, depending on if the format
element FF is used.

Allowed separators, same as TO_CHAR():
space, tab and any of !#%'()*+,-./:;<=>

'&' can also be used if next character is not a character a-z or A-Z
"text' indicates a text string that is verbatim in the format. One cannot
use " as a separator.

Format elements supported by TO_DATE():
AD Anno Domini ("in the year of the Lord")
AD_DOT Anno Domini ("in the year of the Lord")
AM Meridian indicator (Before midday)
AM_DOT Meridian indicator (Before midday)
DAY Name of day
DD Day (1-31)
DDD Day of year (1-336)
DY Abbreviated name of day
FF[1-6] Fractional seconds
HH Hour (1-12)
HH12 Hour (1-12)
HH24 Hour (0-23)
MI Minutes (0-59)
MM Month (1-12)
MON Abbreviated name of month
MONTH Name of Month
PM Meridian indicator (After midday)
PM_DOT Meridian indicator (After midday)
RR 20th century dates in the 21st century. 2 digits
50-99 is assumed from 2000, 0-49 is assumed from 1900.
RRRR 20th century dates in the 21st century. 4 digits
SS Seconds
SYYYY Signed 4 digit year; MariaDB only supports positive years
Y 1 digit year
YY 2 digits year
YYY 3 digits year
YYYY 4 digits year

Note that if there is a missing part of the date, the current date is used!
For example if 'MM-DD HH-MM-SS' then the current year will be used.
(Oracle behaviour)

Not supported options:
- BC, D, DL, DS, E, EE, FM, FX, RM, SSSSS, TS, TZD, TZH, TZR, X,SY
BC is not supported by MariaDB datetime.
- Most of the other are exotic formats does not make sence in MariaDB as
we return datetime or datetime with fractions, not string.
- D (day-of-week) is not supported as it is not clear exactly how it would
map to MariaDB. This element depends on the NLS territory of the session.
- RR only works with 2 digit years (In Oracle RR can also work with 4
digit years in some context but the rules are not clear).

Extensions / differences compared to Oracle;
- MariaDB supports FF (fractional seconds). If FF[#] is used,
then TO_DATE will return a datetime with # of subseconds.
If FF is not used a datetime will be returned.
There is warning (no error) if string contains more digts than what
is specified with F(#]
- Names can be shortened to it's unique prefix. For example January and Ja
works fine.
- No error if the date string is shorter format_string and the next
not used character is not a number.. This is useful to get a date
from a mixed set of strings in date or datetime format.
Oracle gives an error if date string is too short.
- MariaDB supports short locales as language names
- NLS_DATE_FORMAT can use both " and ' for quoting.
- NLS_DATE_FORMAT must be a constant string.
- This is to ensure that the server knows which locale to use
when executing the function.

New formats handled by TO_CHAR():
FF[1-6] Fractional seconds
DDD Daynumber 1-366
IW Week 1-53 according to ISO 8601
I 1 digit year according to ISO 8601
IY 2 digit year according to ISO 8601
IYY 3 digit year according to ISO 8601
IYYY 4 digit year according to ISO 8601
SYYY 4 digit year according to ISO 8601 (Oracle can do signed)

Supported NLS_FORMAT_STRING options are:
NLS_CALENDAR=GREGORIAN
NLS_DATE_LANGUAGE=language

Support languages are:
- All MariaDB short locales, like en_AU.
- The following Oracle language names:
ALBANIAN, AMERICAN, ARABIC, BASQUE, BELARUSIAN, BRAZILIAN PORTUGUESE
BULGARIAN, CANADIAN FRENCH, CATALAN, CROATIAN, CYRILLIC SERBIAN CZECH,
DANISH, DUTCH, ENGLISH, ESTONIAN, FINNISH, FRENCH, GERMAN,
GREEK, HEBREW, HINDI, HUNGARIAN, ICELANDIC, INDONESIAN ITALIAN,
JAPANESE, KANNADA, KOREAN, LATIN AMERICAN SPANISH, LATVIAN,
LITHUANIAN, MACEDONIAN, MALAY, MEXICAN SPANISH, NORWEGIAN, POLISH,
PORTUGUESE, ROMANIAN, RUSSIAN, SIMPLIFIED CHINESE, SLOVAK, SLOVENIAN,
SPANISH, SWAHILI, SWEDISH, TAMIL, THAI, TRADITIONAL CHINESE, TURKISH,
UKRAINIAN, VIETNAMESE

Development bugs fixed:
MDEV-38403 Server crashes in Item_func_to_date::fix_length_and_dec upon
using an invalid argument
MDEV-38400 compat/oracle.func_to_date fails with PS protocol and cursor
protocol (Fixed by Serg)
MDEV-38404 TO_DATE: MTR coverage omissions, round 1
MDEV-38509 TO_DATE: AD_DOT does not appear to be supported
MDEV-38513 TO_DATE: NULL value for format string causes assertion failure
MDEV-38521 TO_DATE: Date strings with non-ASCII symbols cause warnings
and wrong results
MDEV-38578 TO_DATE: Possibly unexpected results upon wrong input
MDEV-38582 TO_DATE: NLS_DATE_LANGUAGE=JAPANESE does not parse values
which work in Oracle
MDEV-38584 TO_DATE: NLS_DATE_LANGUAGE=VIETNAMESE does not parse values
which work in Oracle
MDEV-38703 TO_DATE: Quotation for multi-word NLS_DATE_LANGUAGE leads
to syntax error in view definition
MDEV-38675 TO_DATE: MSAN/Valgrind/UBSAN errors in
extract_oracle_date_time
MDEV-38635 TO_DATE: UBSAN errors in item_timefunc.h upon comparison with
a view column
MDEV-38719 TO_DATE: Assertion `&my_charset_bin != charset()' failed in
String::append_for_single_quote_using_mb_wc
MDEV-38756 TO_DATE: MSAN/Valgrind errors in
Item_func_to_date::fix_length_and_dec upon PREPARE with
parameters

Known issues:
- Format string character matches inside quotes are done
one-letter-to-one-letter, like in LIKE predicate. That means things
like expansions and contractions do not work.
For example 'ss' does not match 'ß' in collations which treat them
as equal for the comparison operator.
Match is done taking into account case and accent sensitivity
of the subject argument collation, so for example this now works:
MariaDB [test]> SELECT TO_DATE('1920á12','YYYY"a"MM') AS c;
+---------------------+
| c |
+---------------------+
| 1920-12-17 00:00:00 |
+---------------------+

Co-author and reviewer: Alexander Barkov <[email protected]>

d5db6c1daa13...

d5db6c1daa132acc85dfbbdd35724031db6843fe

Hemant Dangi

hemant.dangi@galeracluster.com

MDL BF-BF conflict on ALTER and INSERT with multi-level foreign key parents

Issue:
On galera write node INSERT statements does not acquire MDL locks on it's all child
tables and thereby wsrep certification keys are also added for limited tables, but
on applier nodes it does acquire MDL locks for all child tables. This can result
into MDL BF-BF conflict on applier node when transactions referring to parent and
child tables are executed concurrently. For example:

Tables with foreign keys: t1<-t2<-t3<-t4
Conflicting transactions: INSERT t1 and DROP TABLE t4

Wsrep certification keys taken on write node:
- for INSERT t1: t1 and t2
- for DROP TABLE t4: t4

On applier node MDL BF-BF conflict happened between two transaction because
MDL locks on t1, t2, t3 and t4 were taken for INSERT t1, which conflicted
with MDL lock on t4 taken by DROP TABLE t4.
The Wsrep certification keys helps in resolving this MDL BF-BF conflict by
prioritizing and scheduling concurrent transactions. But to generate Wsrep
certification keys it needs to open and take MDL locks on all the child tables.

On applier nodes Write_rows event is implicitly a REPLACE, deleting all conflicting
rows which can cause cascading FK actions and locks on foreign key children tables.

Solution:
For Galera applier nodes the Write_rows event is considered pure INSERT
which will never cause cascading FK actions and locks on foreign key children tables.

d5ae4626d71b...

d5ae4626d71b90be5208c82a6d7618b57ea49202

Sergei Petrunia

sergey@mariadb.com

Add comment about Debug_key.

cbece3a0bf93...

cbece3a0bf9378006d15454628d2fc5a29a59168

Marko Mäkelä

marko.makela@mariadb.com

squash! 091c2b39fe584529c51e1b2d8e416ed2fe96e1eb

innodb_log_recovery_target: When this is set, all persistent InnoDB tables
will be read-only, and no writes to the log are allowed. The intended
purpose of this setting is to prepare an incremental backup, as well as
to allow data retrieval as of a particular logical point of time.

Setting nonzero innodb_log_recovery_target is much like setting
innodb_read_only=ON, with the exception that the data files may be written
to by crash recovery, and locking reads will conflict with any incomplete
transactions as necessary, and all transaction isolation levels will work
normally (not hard-wired to READ UNCOMMITTED).

srv_read_only_mode: When this is set (innodb_read_only=ON), also
recv_sys.rpo (innodb_log_recovery_target) will be set to the current LSN.
This ensures that it will suffice to check only one of these variables.

c0781c08dfc2...

c0781c08dfc2af9af050fdd1680fdca68e25ceb6

Sergei Petrunia

sergey@mariadb.com

MDEV-38753: Debugging help: print which MEM_ROOT the object is on

Add two functions intended for use from debugger:
bool dbug_is_mem_on_mem_root(MEM_ROOT *mem_root, void *ptr);
const char *dbug_which_mem_root(THD *thd, void *ptr);

Also, collect declarations of all other functions intended for use
from debugger in sql/sql_test.h

b29d3779e42f...

b29d3779e42f1cf65b1bbe84876767122dcc76c8

Sergei Golubchik

serg@mariadb.org

Merge branch '10.6' into 10.11

aa485554e365...

aa485554e3650e66d6cefb47ca652be66a5ca601

Yuchen Pei

ycp@mariadb.com

MDEV-24813 Signal full scan to storage engines, with innodb implementation

a9e353e84f15...

a9e353e84f15c8386e756ef1a49ccde227d2d48b

Monty

monty@mariadb.org

MDEV-38246 aria_read index failed on encrypted database during backup

The backup of encrypted Aria tables was not supported.
Added support for this. One complication is that the page checksum is
for the not encrypted page. To be able to verify the checksum I have to
temporarly decrypt the page.
In the backup we store the encrypted pages.

Other things:
- Fixed some (not critical) memory leaks in mariabackup

a30fe0f39067...

a30fe0f39067b2f4c079d8fb2e7c3ed8217ea361

Marko Mäkelä

marko.makela@mariadb.com

fixup! 091c2b39fe584529c51e1b2d8e416ed2fe96e1eb

Simplify recv_sys_t::find_checkpoint_archived()

a2b62fe57257...

a2b62fe57257b1563b5078ddd4934fef9f3b3c3b

Sergei Golubchik

serg@mariadb.org

MDEV-38246 aria_read index failed on encrypted database during backup

Skip an all-zero pages in the index file.
They can happen normally if the ma_checkpoint_background
thread flushes some later page first (e.g. page 50 before page 48).

Also:
* don't do alloca() in a loop
* correct the check in ma_crypt_index_post_read_hook(),
the page can be completely full
* compilation failure in ma_open.c:1289:
comparison is always false due to limited range of data type

9f28e7be59de...

9f28e7be59de58b92573351cd69978d7602feb34

Marko Mäkelä

marko.makela@mariadb.com

MDEV-23298 fixup: have_perfschema.inc

8906e6a214ab...

8906e6a214ab7d151e44c994cd9149fe3d45d114

Aleksey Midenkov

midenok@gmail.com

MDEV-32317 ref_ptrs exhaust on multiple ORDER by func from winfunc

Each ORDER and WHERE slot may generate split, see code like this:

if ((item->with_sum_func() && item->type() != Item::SUM_FUNC_ITEM) ||
item->with_window_func())
item->split_sum_func(thd, ref_ptrs, all_fields, SPLIT_SUM_SELECT);

Such kind of code is done in JOIN::prepare(), setup_order(),
setup_fields(), setup_group() and split_sum_func2() itself.

Since we are at the phase of ref_ptrs allocation, items are not fixed
yet and we cannot calculate precisely how much ref_ptrs is needed. We
can estimate at most how much is needed. In the worst case each window
function generates split on each ORDER BY field, GROUP BY field and
WHERE field, so the counts of these should be multiplied by window
funcs count.

As the split can be done in both setup_without_group() and
JOIN::prepare() simultaneously, the factor of window funcs should be
multiplied by 2.

The similar case may be with inner sumfunc items as of the condition

item->with_sum_func() && item->type() != Item::SUM_FUNC_ITEM

but factor of these is harder to predict at the stage of unfixed
items.

8070033e475d...

8070033e475d34b0ba311c5e522b438849a10bd6

Yuchen Pei

ycp@mariadb.com

MDEV-36230 Fix SERVER port field bound check

The Port field in the system table mysql.servers has type INT,
which translates to Field_long.

During parsing it is parsed as ulong_num, and in this patch we add
bound checks there.

7c37040eb013...

7c37040eb013708f2868fad24dc14d2c63fb5e81

Sergei Golubchik

serg@mariadb.org

fixup! 75af915370ae

7614f8fb5d0f...

7614f8fb5d0f6f808ac261edf689c1eceede5cd9

Marko Mäkelä

marko.makela@mariadb.com

MDEV-38589: SELECT unnecessarily waits for log write

The design of "binlog group commit" involves carrying some state across
transaction boundaries. This includes trx_t::commit_lsn, which keeps track
of how much write-ahead log needs to be written. Unfortunately, this
field was not reset in a commit where a log write was elided. That would
cause an unnecessary wait in a subsequent read-only transaction that
happened to reuse the same transaction object.

trx_deregister_from_2pc(): Reset trx->commit_lsn so that
an earlier write that was executed in the same client connection
will not result in an unnecessary wait during a subsequent read
operation.

trx_commit_complete_for_mysql(): Unless we are inside a binlog
group commit, reset trx->commit_lsn.

unlock_and_close_files(): Reset trx->commit_lsn after durably
writing the log, and remove a redundant log write call from some
callers.

trx_t::rollback_finish(): Clear commit_lsn, because a rolled-back
transaction will not need to be durably written.

trx_t::clear_and_free(): Wrapper function to suppress a debug check
in trx_t::free().

Also, remove some redundant ut_ad(!trx->will_lock) that will be checked
in trx_t::free().

Reviewed by: Vladislav Vaintroub

705a444c0bc0...

705a444c0bc0ada83bcf19ea03da9848f369635a

Alexander Barkov

bar@mariadb.com

MDEV-10152 Add support for TYPE .. IS REF CURSOR

Version#2

In progress

6f2a99589b28...

6f2a99589b28ae53fa5562864fe38f372f4b1c67

bsrikanth-mariadb

srikanth.bondalapati@mariadb.com

MDEV-35815: use-after-poison_in_get_hash_symbol

In find_field_in_view(), we call field_it.create_item() which
creates item on a statement mem_root.
Then we set its name. Make sure the name is allocated on a statement
mem_root, too.

6d2ea07a938e...

6d2ea07a938efbc71518059232d1b0e8d79f7531

Sergei Golubchik

serg@mariadb.org

fixup! 75af915370ae

697e26f4798f...

697e26f4798f90c8c25e5fcd70a4bb236c38e0e5

Sergei Golubchik

serg@mariadb.org

fixup! not a chistic

5bb52ff1145c...

5bb52ff1145c337bcdd1837201fb778f81927a52

Thirunarayanan Balathandayuthapani

thiru@mariadb.com

MDEV-36436 Avoid undo log on insertion of intermediate table during Ignore DDL

Problem:
=========
An assertion failure occurs in InnoDB during consecutive
ALTER TABLE operations using the COPY algorithm. The crash
happens during the table rename phase because the
source table (dict_table_t::n_ref_count) is non-zero, despite
the thread holding an exclusive Metadata Lock (MDL).

Reason:
========
When ALTER IGNORE TABLE is executed via the COPY algorithm,
it generates undo logs for every row inserted into the
intermediate table (e.g., #sql-alter-...). The background Purge
Thread, responsible for cleaning up these undo logs, attempts
to take an MDL on the table to prevent the table from
being dropped while in use.

Race condition:
==================
First ALTER: Creates #sql-alter-, copies data, and renames it to t1.

Purge Activation: The Purge thread picks up the undo logs from step 1.
It takes an MDL on the temporary name (#sql-alter-) and increments
the table's n_ref_count.

Identity Shift: InnoDB renames the physical table object to t1, but
the Purge thread still holds a reference to this object.

Second ALTER: Starts a new copy process. When it attempts to rename
the "new" t1 to a backup name, it checks if n_ref_count == 0.
Because the Purge thread is still "pinning" the object to
clean up logs from the first ALTER, the count is > 0,
triggering the assertion failure.

Solution:
========
ALTER IGNORE TABLE needs row-level undo logging to easily
roll back the last inserted row in case of duplicate key errors.
By discarding the last undo log record after inserting each row,
purge will not process any log records generated by
ALTER IGNORE TABLE, preventing unexpected access from the purge
subsystem during subsequent DDL operations.

Rename skip_alter_undo (1-bit) to alter_undo_mode (2-bit enum)
to support different ALTER operation modes:

- NO_UNDO (0): Normal mode with standard undo logging
- SKIP_UNDO (1): ALTER mode that skips undo logging
- IGNORE_UNDO (2): ALTER IGNORE mode that rewrites undo blocks

trx_undo_report_row_operation(): Add ALTER IGNORE undo
rewriting logic. Store old undo record info before writing
new records for IGNORE_UNDO mode. Reset undo top_offset
and top_undo_no to maintain only latest insert undo

5b6ad325d2e5...

5b6ad325d2e523b95ab7463f093bd8c0d9529edd

Thirunarayanan Balathandayuthapani

thiru@mariadb.com

MDEV-38667 Assertion in diagnostics area on DDL stats timeout

Reason:
======
During InnoDB DDL, statistics updation fails due to lock wait
timeout and calls push_warning_printf() to generate warnings
but then returns success, causing the SQL layer
to attempt calling set_ok_status() when the diagnostics area
is already set.

Solution:
=========
By temporarily setting abort_on_warning to false around operations
that prevents warning to error escalation and restore the original
setting after calling HA_EXTRA_END_ALTER_COPY for alter operation.

554587b8f7a6...

554587b8f7a6a7e743de65e429791d2959470585

Sergei Petrunia

sergey@mariadb.com

MDEV-38273: Optimizer trace should have selectivities collected via sampling

Add to optimizer trace:
"sampled_selectivity": [
{ "cond":"condition", "selectivity": n.nnnn }
...
]

4802bfe4f907...

4802bfe4f9071c2963980fa8c913aee1577a0187

Sergei Golubchik

serg@mariadb.org

MDEV-38710 Assertion is_lock_owner on error returning from auto-create in mysql_admin_table

don't auto-add new partitions if we're already at TIMESTAMP_MAX_VALUE

3393df591930...

3393df5919301e474191c827c9b804f2b9fcdb2d

Sergei Golubchik

serg@mariadb.org

Merge branch '12.2' into 12.3

3218602d3100...

3218602d3100db9ce7a875511a591cddc173cc16

Brandon Nesterenko

brandon.nesterenko@mariadb.com

MDEV-25039: MDL BF-BF conflict because of foreign key

Fix rpl suite tests added by MDEV-25039.

rpl_foreign_key_lock_table_insert.test is removed altogether because it
is unclear what the purpose of the test is. The changes of the patch
were done on the slave, yet all operations in the test were done on the
master. Nothing different could happen on the slave because it is
configured to be serial, so all transactions would run sequentially
anyway, and no validations were performed.

rpl_foreign_key_ddl_insert.test was renamed to
rpl_row_foreign_key_mdl.test and the test itself was re-written to be
a minimal test case to ensure that MDL locking behavior is different
pre- and post- patch. A few problems with the original test:
* No foreign-key locking was done on the slave because the table
engine was not InnoDB.
* rpl_fk_ddl.inc had inconsistent validation checking. I.e., the child
query validation checks were done on the master (which is incorrect)
and because the slave was configured to be serial, the two
transactions could not run concurrently on the slave anyway.

2ec54796db42...

2ec54796db4298a559f36ca9b811f781e46fa8ef

Dave Gosselin

dave.gosselin@mariadb.com

MDEV-38747: ASAN errors in Optimizer_hint_parser::Identifier::to_ident_cli

Summary:
A trigger specifying a hint where the hint has a query block name will cause
an ASAN failure because hint resolution occurs after query parsing, not
during query parsing. The trigger execution logic uses a stack-local
string to hold the query and hint text during parsing. In trigger execution,
query parsing and query execution happen in different function contexts, so
the query string used during parsing goes out of scope, freeing its memory.
But as hint resolution occurs after parsing is complete (and hints merely
point into the query string, they don't copy from it), the hints refer into
a deallocated query string upon hint resolution.

Details:
Prior to the commit introducing this bug, hint resolution was done via a call
to `LEX::resolve_optimizer_hints_in_last_select` when parsing the
`query_specification:` grammar rule. This meant that any string containing
the query (and hints) was in scope for the entire lifetime of query parsing
and hint resolution.

In the patch introducing this bug, `resolve_optimizer_hints_in_last_select`
was changed to merely cache hints for resolution during query execution.
Upon query execution, `mysql_execute_command` calls `LEX::resolve_optimizer_hints`
to resolve hints and this is after query parsing. `sp_instr::parse_expr`
reparses the query associated with a trigger and does so using a stack-local
String variable to hold the query text. `sp_instr::parse_expr` returns after
query parsing completes but before hint resolution begins. Since
the string holding the query was stack-local in `sp_instr::parse_expr` and
destroyed when the method returned, the query string (and hints with it) were
deallocated, leading to the ASAN failure on hint resolution. When executing
the trigger, `sp_instr_stmt::exec_core` calls `mysql_execute_command` which
calls `LEX::resolve_optimizer_hints` to complete hint resolution but the query
string that the hints depends on no longer exists at this point.

As noted, the stack-local `query_string` variable in `sp_inst::parse_expr` goes
out-of-scope and is freed when the `sp_lex_instr::parse_expr` returns. In
contrast, in the general case, when a `COM_QUERY` is processed during
`dispatch_command`, the query string lives on the `THD` for the lifetime of
the query independent of some particular function's scope.

For triggers, the necessary lifetime of that query string needs to be as long
as `sp_lex_keeper::validate_lex_and_exec_core` which covers both the query
string parsing via `sp_instr::parse_expr` and the procedure's execution during
`reset_lex_and_exec_core`. Consequently, this patch lifts the `query_string`
buffer up out of `parse_expr` and passes a pointer to it into `parse_expr` to
guarantee the query string's lifetime across parsing and execution, for hint
resolution.

QB_NAME is not the only affected hint kind; hints with some query block
identifier text for the query block, like
```
NO_MERGE(`@select#1`)
```
will also cause the crash while `NO_MERGE()` will not.

2dd6f1f7a943...

2dd6f1f7a943efb24ffdf1bfad143a5b170f5e17

Sergei Golubchik

serg@mariadb.org

bump the VERSION

1c5abb3d1089...

1c5abb3d10898700b8ee69d9340995805dcea22a

Dave Gosselin

dave.gosselin@mariadb.com

14eb69567ed9...

14eb69567ed916c9dc963209fec4046e9830c80c

Sergei Golubchik

serg@mariadb.org

MDEV-38744 remove galera dependency from server packages

12578d8a69c9...

12578d8a69c9529b080c5e910d53920a8b4f758d

Sergei Golubchik

serg@mariadb.org

MDEV-38604 fix SP execution too

0b73d7b59226...

0b73d7b59226cdac15cb12faca12e2d62b7bf30a

Marko Mäkelä

marko.makela@mariadb.com

fixup! cbece3a0bf9378006d15454628d2fc5a29a59168

Fix mysql-test/mtr --suite=mariabackup

07ea7a2d8a89...

07ea7a2d8a895eb91ab1fd09e905dcd31965df52

Thirunarayanan Balathandayuthapani

thiru@mariadb.com

07760aba1bc1...

07760aba1bc1b0ec400a2f243077adee43898c36

ParadoxV5

paradox.ver5@gmail.com

Merge branch '10.11' into MDEV-4698

05e6c9d42d2f...

05e6c9d42d2f49ada1a0c49a4e0d7fc3ce420e4e

Sergei Golubchik

serg@mariadb.org

MDEV-32317 fix the test for --view

0294816cef2a...

0294816cef2a27a883e2715ca1908eef19cd3084

ParadoxV5

paradox.ver5@gmail.com

MDEV-4698 snapshot 5

This should be ready for review now. Though there are still CI problems,
so it’s really the design with proof of concept that’s ready.

* Don’t depend on `@@sql_slave_skip_counter`. Don’t depend on
`@@gtid_ignore_duplicates` either, lest history repeats itself.
Add a skip override in `apply_event_and_update_pos()` instead.
* Skip unflagging when outside of a transaction as well,
which leaves GTID events to be the harbinger of truth
* Fix standaline events not skipped
* Fix another bunch of tests (They really assumed clearing
`Gtid_Slave_Pos` clears ` Gtid_IO_Pos` as well.)