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.
Showing
Please register or sign in to comment