[Commits] b97452a6204: MDEV-19491 update query stopped working after mariadb upgrade 10.2.23 -> 10.2.24
serg at mariadb.org
Thu May 30 23:30:56 EEST 2019
On May 30, Sergey Vojtovich wrote:
> > The problem was that it's fairly difficult to detect the last
> > handle_table() call. It's the call for the last updatable table
> > which isn't a view, and isn't information_schema table. Then there
> > was some issue with routines that are opened after tables, and it
> > was too late. I was fixing all those problems but finally I've
> > basically given up. I'm not sure anymore what the last problem was,
> > probably the one with information_schema tables (handle_table()
> > isn't called for them).
> I think it implies that we have to open all query tables before
> evalutation. My second question was: do we actually have to do it
> this way?
I'm not quite sure what part of the original
mysql_multi_update_prepare() really has to be done in handle_end().
Obviously all tables explicitly mentioned in the statement has to be
opened and their fields has to be fixed. That's the whole point - we
need to know what table the field in `SET a=5` belongs to.
To what extent views and derived tables has to be prepared - I cannot
say. It looks like we have to merge all mergeable views and derived for
the same reason as above, to find what table the field `a` belongs to.
Clearly, any table not mentioned in a statement (nor in any views)
doesn't have to be opened - tables coming via triggers or stored
routines cannot be updated.
> One question re is_stmt_prepare() is not answered.
Yes, this branch is definitely used with is_stmt_prepare() == true.
Any prepare of a multi-update does it.
Just to be sure, I've added an assert there and it immediately crashed
in multi_update test on
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'
Chief Architect MariaDB
and security at mariadb.org
More information about the commits