MariaDB

maria:bb-10.8-MDEV-27233

Git
lp:maria
bb-10.8-MDEV-27233

Last commit made on 2022-10-07

Get this branch:: git clone -b bb-10.8-MDEV-27233 https://git.launchpad.net/maria

Branch merges

Branch information

Name:: bb-10.8-MDEV-27233

Repository:: lp:maria

Recent commits

2752fff... by Nayuta Yanagisawa on 2022-04-25

MDEV-27233 Server hangs when using --init-file which loads Spider and creates a Spider table

Spider waits until the server initialization has been completed
(i.e., mysqld_server_started has been set to 1) before creating the
Spider system tables. Spider also wait until the system tables have
been created before instantiating ha_spider.

These waits leads to dead lock when a non-system Spider table is
created by --in-file. This is because queries passed by --in-file
are executed during the server initialization and creating the
non-system Spider causes an instantiation of ha_spider.

In the first place, there seems to be no need for Spider to do such
a synchronization. Thus, we simply remove the synchronization.

a49f5d6... by Alexey Botchkov on 2022-01-18

MDEV-27233 Fixes to make SQL SERVICE working

2f70784... by Oleksandr "Sanja" Byelkin on 2022-10-04

Merge branch '10.7' into 10.8

b6ebada... by Oleksandr "Sanja" Byelkin on 2022-10-04

Merge branch '10.6' into 10.7

fe449af... by Oleksandr "Sanja" Byelkin on 2022-10-03

Merge branch '10.5' into 10.6

7865c8c... by Rucha Deodhar <email address hidden> on 2022-09-26

Crash in INSERT...SELECT..RETURNING with subquery

Underlying causes of all bugs mentioned below are same. This patch fixes
all of them:
1) MDEV-25028: ASAN use-after-poison in
base_list_iterator::next or Assertion `sl->join == 0' upon
INSERT .. RETURNING via PS
2) MDEV-25187: Assertion `inited == NONE || table->open_by_handler'
failed or Direct leak in init_dynamic_array2 upon INSERT .. RETURNING
and memory leak in init_dynamic_array2
3) MDEV-28740: crash in INSERT RETURNING subquery in prepared statements
4) MDEV-27165: crash in base_list_iterator::next
5) MDEV-29686: Assertion `slave == 0' failed in
st_select_lex_node::attach_single

Analysis:
consider this statement:
INSERT(1)...SELECT(2)...(SELECT(3)...) RETURNING (SELECT(4)...)

When RETURNING is encountered, add_slave() changes how selects are linked.
It makes the builtin_select(1) slave of SELECT(2). This causes
losing of already existing slave(3) (which is nested select of SELECT of
INSERT...SELECT). When really, builtin_select (1) shouldn't be slave to
SELECT(2) because it is not nested within it. Also, push_select() to use
correct context also changed how select are linked.
During reinit_stmt_before_use(), we expect the selects to
be cleaned-up and have join=0. Since these selects are not linked correctly,
clean-up doesn't happen correctly so join is not NULL. Hence the crash.

Fix:
IF we are parsing RETURNING, make is_parsing_returning= true for
current select. get rid of add_slave(). In place of push_select(), used
push_context() to have correct context (the context of builtin_select)
to resolve items in item_list. And add these items to item_list of
builtin_select.

900d7bf... by Sergei Golubchik on 2022-10-02