maria:bb-10.6-MDEV-31983

Last commit made on 2023-09-11
Get this branch:
git clone -b bb-10.6-MDEV-31983 https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-10.6-MDEV-31983
Repository:
lp:maria

Recent commits

85b788f... by Rex Johnston

MDEV-31983 jointable materialization subquery optimization ignoring errors, then failing ASSERT.

Add in thread error check after get_quick_record_count() checking for
errors in constructing SEL_TREE.

961b96a... by Nayana

MDEV-29324 s390x patch srw_lock.cc

Fix debug mode build failure on s390x.
Replaced builtin_ttest by __builtin_tx_nesting_depth() > 0 as a s390x equivalent version of the expression.

f009c4d... by Monty <email address hidden>

Small corrections to MDEV-29693 ANALYZE TABLE

32 bit MariaDB crashed in innodb.innodb-16k and a few other tests.
Fixed by using correct sizeof() calls.

Histograms where not read if first read was without histograms.

182a08a... by Monty <email address hidden>

Removed compiler warning from connect/filamdbf.cpp

de5dba9... by Dmitry Shulga <email address hidden>

Merge branch '10.5' into 10.6

68a925b... by Dmitry Shulga <email address hidden>

Merge branch '10.4' into 10.5

b0a4381... by Marko Mäkelä

Merge 10.5 into 10.6

59952b2... by Marko Mäkelä

Merge 10.4 into 10.5

d0a872c... by Dmitry Shulga <email address hidden>

MDEV-14959: Fixed memory leak relating with view and IS

Fixed memory leak taken place on executing a prepared statement or
a stored routine that querying a view and this view constructed
on an information schema table. For example,

Lets consider the following definition of the view 'v1'
CREATE VIEW v1 AS SELECT table_name FROM information_schema.views
ORDER BY table_name;

Querying this view in PS mode result in hit of assert.
PREPARE stmt FROM "SELECT * FROM v1";
EXECUTE stmt;
EXECUTE stmt; (*)

Running the statement marked with (*) leads to a crash in case
server build with mode to control allocation of a memory from SP/PS
memory root on the second and following executions of PS/SP.

The reason of leaking the memory is that a memory allocated on
processing of FRM file for the view requested from a PS/PS memory
root meaning that this memory be released only when a stored routine
be evicted from SP-cache or a prepared statement be deallocated
that typically happens on termination of a user session.

To fix the issue switch to a memory root specially created for
allocation of short-lived objects that requested on parsing FRM.

be02356... by Dmitry Shulga <email address hidden>

MDEV-14959: Fixed memory leak happened on re-parsing a view that substitutes a table

In case a table accessed by a PS/SP is dropped after the first execution of
PS/SP and a view created with the same name as a table just dropped then
the second execution of PS/SP leads to allocation of a memory on SP/PS
memory root already marked as read only on first execution.

For example, the following test case:
CREATE TABLE t1 (a INT);
PREPARE stmt FROM "INSERT INTO t1 VALUES (1)";
EXECUTE stmt;
DROP TABLE t1;
CREATE VIEW t1 S SELECT 1;
--error ER_NON_INSERTABLE_TABLE
EXECUTE stmt; # (*)
DROP VIEW t1;

will hit assert on running the statement 'EXECUTE stmt' marked with (*)
when allocation of a memory be performed on parsing the view.

Memory allocation is requested inside the function mysql_make_view
when a view definition being parsed. In order to avoid an assertion
failure, call of the function mysql_make_view() must be moved after
invocation of the function check_and_update_table_version().
It will result in re-preparing the whole PS statement or current
SP instruction that will free currently allocated items and reset
read_only flag for the memory root.