Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
N/A
Description
CURRENT_TEST: main.multi_update
|
mysqltest: At line 1048: query 'UPDATE t1 t1 left join v3 t2 on t1.f4 = t2.fe2 SET t1.f20 = t2.ft6_1, t1.f32 = t2.f32, t1.f33 = t2.f33, t1.f37 = t2.f37 WHERE f5 >= '2015-02-01'' failed: 1030: Got error 1 from storage engine
|
See also buildbot, e.g. http://buildbot.askmonty.org/buildbot/builders/bld-dan-debug/builds/2062/steps/test_1/logs/stdio
The test started failing from the following commit on 5.5 tree:
commit b9a75862eaa05708921b8fe9773ffe233048bebc
|
Author: Oleksandr Byelkin <sanja@mariadb.com>
|
Date: Thu Mar 5 16:34:13 2015 +0100
|
|
|
MDEV-7613: MariaDB 5.5.40 server crash on update table left join with a view
|
|
Multi-update do not need full list of leaf tables. It also do not use it on prepare (mysql_multi_update_prepare()).
|
Although the failing portion of the test is new, the same updated test passes on the code before the change, so it looks like a code problem.
Attachments
Issue Links
- blocks
-
MDEV-7069 Fix buildbot failures in main server trees
-
- Closed
-
Activity
What happens:
1) PREPARE:
1.1) build leaf table
1.2) mysql_multi_update_prepare merge view and replace view in leaf table list
2) EXECUTE
2.1) forget correct leaf_table and build original leaf table list
2.2) merge already is done so there will not be replace of the table
2.3) incorrect leaf table list saved
2.4) problem because in the list present view which was merged
There is st_select_lex::save_prep_leaf_tables() to solve the problem above, but it is called only for upper level of views.
So it should be recursive function.
revision-id: 782ebec4c667d40c45e350e8f93025bab2f89b0c
parent(s): 4cfb7f9db3d9841fd66aed8da4b5312e88d394cb
committer: Oleksandr Byelkin
branch nick: server
timestamp: 2015-04-22 10:14:11 +0200
message:
MDEV-8018: main.multi_update fails with --ps-protocol
save_prep_leaf_tables() made recursive to work with underlying view
Arena restoiring fixed in case of EOM.
—
mysql_derived_merge replaces tov with ta1 during usual execution, and even PREPARE STATEMANT, but not during PS execution...