Bug#39843 DELETE requires write access to table in subquery in where clause
An unnecessarily restrictive lock were taken on sub-SELECTs during DELETE. During parsing, a global structure is reused for sub-SELECTs and the attribute keeping track of lock options were not reset properly. This patch introduces a new attribute to keep track on the syntactical lock option elements found in a sub-SELECT and then sets the lock options accordingly. Now the sub-SELECTs will try to acquire a READ lock if possible instead of a WRITE lock as inherited from the outer DELETE statement. mysql-test/r/lock.result: Added test case for bug39843 mysql-test/t/lock.test: Added test case for bug39843 sql/sql_lex.cc: * Reset member variable lock_option on each new query. sql/sql_lex.h: * Introduced new member variable 'lock_option' which is keeping track of the syntactical lock option of a (sub-)select query. sql/sql_parse.cc: * Wrote comments to functions. sql/sql_yacc.yy: * Introduced an attribute to keep track of syntactical lock options in sub-selects. * Made sure that the default value TL_READ_DEFAULT is at the begining of each subselect-rule.
Showing
Please register or sign in to comment