maria:bb-10.10-ycp

Last commit made on 2023-10-18
Get this branch:
git clone -b bb-10.10-ycp https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-10.10-ycp
Repository:
lp:maria

Recent commits

c003958... by Yuchen Pei <email address hidden>

MDEV-32485 Fix Spider upgrade failure caused by duplication in mysql.func

f3fe390... by Yuchen Pei <email address hidden>

MDEV-29963 MDEV-31357 Spider should clear its lock lists when locking fails

Spider populates its lock lists (a hash) in store_lock(), and normally
clears them in the actual lock_tables(). However, if lock_tables()
fails, there's no reset_lock() method for storage engine handlers,
which can cause bad things to happen. For example, if one of the table
involved is dropped and recreated, or simply TRUNCATEd, when executing
LOCK TABLES again, the lock lists would be queried again in
store_lock(), which could cause access to freed space associated with
the dropped table.

bbb1853... by Yuchen Pei <email address hidden>

MDEV-26247 Re-implement spider gbh query rewrite of tables

Spider GBH's query rewrite of table joins is overly complex and
error-prone. We replace it with something closer to what
dbug_print() (more specifically, print_join()) does, but catered to
spider.

More specifically, we replace the body of
spider_db_mbase_util::append_from_and_tables() with a call to
spider_db_mbase_util::append_join(), and remove downstream append_X
functions.

We make it handle const tables by rewriting them as (select 1). This
fixes the main issue in MDEV-26247.

We also ban semijoin from spider gbh, which fixes MDEV-31645 and
MDEV-30392, as semi-join is an "internal" join, and "semi join" does
not parse, and it is different from "join" in that it deduplicates the
right hand side

Not all queries passed to a group by handler are valid (MDEV-32273),
for example, a join on expr may refer outer fields not in the current
context. We detect this during the handler creation when walking the
join. See also gbh_outer_fields_in_join.test.

It also skips eliminated tables, which fixes MDEV-26193.

17caa3b... by Yuchen Pei <email address hidden>

MDEV-26247 clean up spider_group_by_handler::init_scan()

6b4d59c... by Yuchen Pei <email address hidden>

MDEV-26247 Clean up spider_fields

Spider gbh query rewrite should get table for fields in a simple way.
Add a method spider_fields::find_table that searches its table holders
to find table for a given field. This way we will be able to get rid
of the first pass during the gbh creation where field_chains and
field_holders are created.

We also check that the field belongs to a spider table while walking
through the query, so we could remove
all_query_fields_are_query_table_members(). However, this requires an
earlier creation of the table_holder so that tables are added before
checking. We do that, and in doing so, also decouple table_holder and
spider_fields

Remove unused methods and fields. Add comments.

b040d38... by Yuchen Pei <email address hidden>

MDEV-26247 Remove some unused spider methods

Two methods from spider_fields. There are probably more of these
conn_holder related methods that can be removed

reappend_tables_part()
reappend_tables()

3457b8b... by Yuchen Pei <email address hidden>

MDEV-28998 remove a known reference to a SPIDER_CONN when it is freed

4fef656... by Yuchen Pei <email address hidden>

MDEV-31996 Create connection on demand in spider_db_delete_all_rows

When spider_db_delete_all_rows() is called, the supplied spider->conns
may have already been freed. The existing mechanism has spider_trx own
the connections in trx_conn_hash and it may free a conn during the
cleanup after a query. When running a delete query and if the table is
in the table cache, ha_spider::open() would not be called which would
recreate the conn. So we recreate the conn when necessary during
delete by calling spider_check_trx_and_get_conn().

We also reduce code duplication as delete_all_rows() and truncate()
has almost identical code, and there's no need to assign
wide_handler->sql_command in these functions because it has already
been correctly assigned.

a49ebf7... by Monty <email address hidden>

Fixed memory leak when using histograms

This was introduced in last merge with 10.6
The reason is that 10.6 does not need anything special to free histograms
as everything is allocated on a memroot.
In 10.10 histograms is using the vector class, which has some problems:
- No automatic free
- No memory usage accounting
(we should at some point remove vector usage because of the above problem)

Fixed by expliciting freeing histograms when freeing TABLE_STATISTICS
objects.

0563106... by Marko Mäkelä

Merge 10.6 into 10.10