------------------------------------------------------------
revno: 2572.2.1
revision-id: sp1r-davi@mysql.com/endora.local-20080227225948-16317
parent: sp1r-anozdrin/alik@quad.-20080226165712-10409
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-02-27 19:59:48 -0300
message:
Bug#27525 table not found when using multi-table-deletes with aliases over several databas
Bug#30234 Unexpected behavior using DELETE with AS and USING
The multi-delete statement has a documented limitation that
cross-database multiple-table deletes using aliases are not
supported because it fails to find the tables by alias if it
belongs to a different database. The problem is that when
building the list of tables to delete from, if a database
name is not specified (maybe an alias) it defaults to the
name of the current selected database, making impossible to
to properly resolve tables by alias later. Another problem
is a inconsistency of the multiple table delete syntax that
permits ambiguities in a delete statement (aliases that refer
to multiple different tables or vice-versa).
The first step for a solution and proper implementation of
the cross-databse multiple table delete is to get rid of any
ambiguities in a multiple table statement. Currently, the parser
is accepting multiple table delete statements that have no obvious
meaning, such as:
DELETE a1 FROM db1.t1 AS a1, db2.t2 AS a1;
DELETE a1 AS a1 FROM db1.t1 AS a1, db2.t2 AS a1;
The solution is to resolve the left part of a delete statement
using the right part, if the a table on right has an alias,
it must be referenced in the left using the given alias. Also,
each table on the left side must match unambiguously only one
table in the right side.
------------------------------------------------------------
revno: 2630.2.13
revision-id: davi@mysql.com-20080612190452-cx6h7rm557bcq7sa
parent: davi@mysql.com-20080611124915-csejwrxfdga9upho
committer: Davi Arnaut <davi@mysql.com>
branch nick: 36785-6.0
timestamp: Thu 2008-06-12 16:04:52 -0300
message:
Bug#36785: Wrong error message when group_concat() exceeds max length
The problem is that when ER_CUT_VALUE_GROUP_CONCAT is elevated
to a error, the message does not get updated with the number of
cut lines when group_concat() exceeds max length.
The solution is to modify the warning message to be more meaningful
by giving the number of the line that was cut and to issue the warning
for each line that is cut. This approach is inline with how other
per-row truncated data warnings are issued avoids violating the warning
internal interface.
Detailed revision comments:
r6101 | jyang | 2009-10-23 11:45:50 +0300 (Fri, 23 Oct 2009) | 7 lines
branches/zip: Update test result with the WARN_LEVEL_ERROR
to WARN_LEVEL_WARN change. This is the same result as
submitted in rb://172 review, which approved by Sunny Bains
and Marko.
Detailed revision comments:
r6100 | jyang | 2009-10-22 06:51:07 +0300 (Thu, 22 Oct 2009) | 6 lines
branches/zip: As a request from mysql, WARN_LEVEL_ERROR cannot
be used for push_warning_* call any more. Switch to
WARN_LEVEL_WARN. Bug #47233.
rb://172 approved by Sunny Bains and Marko.
Detailed revision comments:
r6095 | vasil | 2009-10-19 16:04:59 +0300 (Mon, 19 Oct 2009) | 7 lines
branches/zip:
Fix Bug#47808 innodb_information_schema.test fails when run under valgrind
by using the wait_until_rows_count macro that loops until the number of
rows becomes 14 instead of sleep 0.1, which is obviously very fragile.
The 'rpl_get_master_version_and_clock' test verifies if the slave I/O
thread tries to reconnect to master when it tries to get the values of
the UNIX_TIMESTAMP, SERVER_ID from master under network disconnection.
So the master server is restarted for making the transient network
disconnection. Restarting master server can bring two problems as following:
1. The time out error is encountered sporadically. The slave I/O thread tries
to reconnect master ten times, which is set in my.cnf. So in the test
framework sporadically the slave I/O thread really stoped when it can't
reconnect to master in the ten times successfully before the master starts,
then the time out error will be encountered while waiting for the slave to
start.
2. These warnings and errors are produced in server log file when
the slave I/O thread tries to get the values of the UNIX_TIMESTAMP,
SERVER_ID from master under the transient network disconnection.
To fix problem 1, increase the master retry count to sixty times,
so that the slave I/O thread has enough time to reconnect master
successfully.
To fix problem 2, suppress these warnings and errors by mtr suppression,
because they are expected.
binlog, replication aborts
In SBR or MBR, the schema name is not being written to the binlog
when executing a LOAD DATA statement. This becomes a problem when
the current database (lets call it db1) is different from the
table's schema (lets call it db2). For instance, take the
following statements:
use db1;
load data local infile 'infile.txt' into table db2.t
Should this statement be logged without t's schema (db2), when
replaying it, one can get db1.t populated instead of db2.t (if
db1.t exists). On the other hand, if there is no db1.t at all,
replication will stop.
We fix this by always logging the table (in load file) with fully
qualified name when its schema is different from the current
database or when no default database was selected.
Fixed problems:
- "mtr --mem mysql_locale_posix" could fail because of wrong temporary
directory name: var/tmp/ -> $MYSQLTEST_VARDIR/tmp/
- "mtr federated_debug" could fail because of not compiled-in
locale character set. Always run mysqladmin with latin1.
Conflicts
=========
Text conflict in .bzr-mysql/default.conf
Text conflict in libmysqld/CMakeLists.txt
Text conflict in libmysqld/Makefile.am
Text conflict in mysql-test/collections/default.experimental
Text conflict in mysql-test/extra/rpl_tests/rpl_row_sp006.test
Text conflict in mysql-test/suite/binlog/r/binlog_tmp_table.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata_fatal.result
Text conflict in mysql-test/suite/rpl/r/rpl_row_create_table.result
Text conflict in mysql-test/suite/rpl/r/rpl_row_sp006_InnoDB.result
Text conflict in mysql-test/suite/rpl/r/rpl_stm_log.result
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_circular_simplex.result
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_sp006.result
Text conflict in mysql-test/t/mysqlbinlog.test
Text conflict in sql/CMakeLists.txt
Text conflict in sql/Makefile.am
Text conflict in sql/log_event_old.cc
Text conflict in sql/rpl_rli.cc
Text conflict in sql/slave.cc
Text conflict in sql/sql_binlog.cc
Text conflict in sql/sql_lex.h
21 conflicts encountered.
NOTE
====
mysql-5.1-rpl-merge has been made a mirror of mysql-next-mr:
- "mysql-5.1-rpl-merge$ bzr pull ../mysql-next-mr"
This is the first cset (merge/...) committed after pulling
from mysql-next-mr.
