[MDEV-8018] main.multi_update fails with --ps-protocol Created: 2015-04-19  Updated: 2015-04-23  Resolved: 2015-04-22

Status: Closed
Project: MariaDB Server
Component/s: Optimizer, Tests
Affects Version/s: N/A
Fix Version/s: 5.5.43

Type: Bug Priority: Blocker
Reporter: Elena Stepanova Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: regression

Issue Links:
Blocks
blocks MDEV-7069 Fix buildbot failures in main server ... Stalled

 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.



 Comments   
Comment by Oleksandr Byelkin [ 2015-04-20 ]

Temporary table tov looks like have empty (but initialized) ha_memory (not opened?)

Comment by Oleksandr Byelkin [ 2015-04-20 ]

tov was merged just before it

Comment by Oleksandr Byelkin [ 2015-04-21 ]

difference in WHERE between prepare and usual execution

usual:
WHERE:(after remove) 0x7fffe80b49b0 (multiple equal(`t1c`.`ft3`, `ua`.`ft3`) and multiple equal(`t1c`.`fe2`, `ua`.`fe2`))

PS:
WHERE:(after remove) 0x7fffe80adb68 ((`t1c`.`fe8` = `t1a`.`ft4`) and (if((`t1a`.`ft10` = 'virtuell'),0,1) = 1) and multiple equal(`t1c`.`ft3`, `ua`.`ft3`) and multiple equal(`t1c`.`fe2`, `ua`.`fe2`))

Comment by Oleksandr Byelkin [ 2015-04-21 ]

the difference about caused by elimination t1a. All other sequence of processing derived tables (in general looks the same).

So the question is how temporary table of a merged view got in JOIN_TAB...

Comment by Oleksandr Byelkin [ 2015-04-21 ]

mysql_derived_merge replaces tov with ta1 during usual execution, and even PREPARE STATEMANT, but not during PS execution...

Comment by Oleksandr Byelkin [ 2015-04-21 ]

derived->merged is set so merge do nothing...

Comment by Oleksandr Byelkin [ 2015-04-22 ]

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

Comment by Oleksandr Byelkin [ 2015-04-22 ]

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.

Comment by Oleksandr Byelkin [ 2015-04-22 ]

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.

—

Generated at Thu Feb 08 07:24:01 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.