summaryrefslogtreecommitdiff
path: root/heap
diff options
context:
space:
mode:
authorunknown <guilhem@mysql.com>2004-01-29 19:22:29 +0100
committerunknown <guilhem@mysql.com>2004-01-29 19:22:29 +0100
commit8746a25554d18f03fc32ca5d338850f9308bee88 (patch)
treef3f426fbb085bed11fbaa55547d74f9feaec62a8 /heap
parent163dffb4d0057c41b518860bf1063c665ccebb4d (diff)
downloadmariadb-git-8746a25554d18f03fc32ca5d338850f9308bee88.tar.gz
Fix for BUG#2527 "Multi-Table Delete - Not Replication use replicate-wild-do-table"
(as long as replicate-*-table rules were defined, multi-table DELETE was never replicated by the slave). sql/sql_parse.cc: For a multi-table DELETE, there are two lists of tables: - 'tables' contains the tables in the FROM. They have 'updating==0'. - 'thd->lex.auxilliary_table_list.first' contains the tables between the DELETE and the FROM. They have 'updating==1'. So the bug was that the slave only tests 'tables' and as all its elements have updating==0, tables_ok() always returns 0. So for a multi DELETE the slave now tests the 2nd list too. I started with the other tip of the sausage: I thought of changing multi DELETE to use only one list (given that 'updating' can be used to separate it in two when needed) (with one list we wouldn't need to change the slave code), but finally hit the unicity check in add_table_to_list() which started to return ER_NONUNIQ_TABLE (logical).
Diffstat (limited to 'heap')
0 files changed, 0 insertions, 0 deletions