- 09 Jul, 2006 2 commits
-
-
unknown authored
were copied/split between 5.0 and 5.1). mysql-test/extra/rpl_tests/rpl_auto_increment.test: manual merge of test from 5.0 mysql-test/extra/rpl_tests/rpl_insert_id.test: manuel merge of test from 5.0 mysql-test/r/rpl_auto_increment.result: error messages changed compared to 5.0
-
unknown authored
into gbichot3.local:/home/mysql_src/mysql-5.1 mysql-test/r/rpl_auto_increment.result: Auto merged mysql-test/r/rpl_insert_id.result: Auto merged mysql-test/t/rpl_openssl.test: Auto merged sql/ha_ndbcluster.cc: Auto merged mysql-test/t/rpl_auto_increment.test: will fix by hand mysql-test/t/rpl_insert_id.test: will fix by hand sql/handler.cc: comment sql/handler.h: manual merge sql/sql_insert.cc: manual merge
-
- 08 Jul, 2006 1 commit
-
-
unknown authored
Fixing typo and potential memory problem. Reducing number of concurrent mysqlslap threads since tests fail in pushbuild due to too many threads. mysql-test/r/rpl_insert.result: Result change. mysql-test/t/rpl_insert.test: Reducing number of threads since it doesn't pass pushbuild. sql/sql_insert.cc: Fixing typo and potential memory problem.
-
- 07 Jul, 2006 10 commits
-
-
unknown authored
mysys/my_malloc.c: Changing prototype for my_strndup(). server-tools/instance-manager/parse.h: Changing prototype for my_strndup().
-
unknown authored
-
unknown authored
Previous patch didn't work: moving variable settings inside critical region. sql/slave.cc: Moving variable setting inside critical region (again) when terminating slave I/O thread.
-
unknown authored
into romeo.(none):/home/bk/b20821-mysql-5.1-new-rpl
-
unknown authored
in pushbuild on Replication/Backup team tree. include/my_sys.h: Using "char" instead of "byte" for my_strndup(). mysys/safemalloc.c: Using "char" instead of "byte" for my_strndup().
-
unknown authored
into romeo.(none):/home/bkroot/mysql-5.1-new-rpl
-
unknown authored
into eucla.lemis.com:/home/MySQL/5.1-Bug-20850
-
unknown authored
BUG#20850: Assert during slave shutdown in many rpl_* tests. This was caused by a race condition at the end of handle_slave_io which under some circumstances allowed the cleanup to proceed before the thread had completed. sql/slave.cc: BUG#20850: Assert during slave shutdown in many rpl_* tests. This was caused by a race condition at the end of handle_slave_io which under some circumstances allowed the cleanup to proceed before the thread had completed.
-
unknown authored
Tidy up white space. sql/slave.cc: Tidy up white space.
-
unknown authored
mysql-test/t/rpl_insert.test: Adding sleep to allow mysqlslap to finish.
-
- 06 Jul, 2006 3 commits
-
-
unknown authored
into gbichot3.local:/home/mysql_src/mysql-5.0
-
unknown authored
into gbichot3.local:/home/mysql_src/mysql-5.0 sql/handler.cc: Auto merged sql/handler.h: Auto merged sql/sql_insert.cc: Auto merged
-
unknown authored
a too large value": the bug was that if MySQL generated a value for an auto_increment column, based on auto_increment_* variables, and this value was bigger than the column's max possible value, then that max possible value was inserted (after issuing a warning). But this didn't honour auto_increment_* variables (and so could cause conflicts in a master-master replication where one master is supposed to generated only even numbers, and the other only odd numbers), so now we "round down" this max possible value to honour auto_increment_* variables, before inserting it. mysql-test/r/rpl_auto_increment.result: result update. Before the fix, the result was that master inserted 127 in t1 (which didn't honour auto_increment_* variables!), instead of failing with "duplicate key 125" like now. mysql-test/t/rpl_auto_increment.test: Test for BUG#20524 "auto_increment_* not observed when inserting a too large value". We also check the pathological case (table t2) where it's impossible to "round down". The fixer of BUG#20573 will be able to use table t2 for testing his fix. sql/handler.cc: If handler::update_auto_increment() generates a value larger than the field's max possible value, we used to simply insert this max possible value (after pushing a warning). Now we "round down" this max possible value to honour auto_increment_* variables (if at all possible), before trying the insertion.
-
- 05 Jul, 2006 4 commits
-
-
unknown authored
mysql-test/t/rpl_insert.test: Fixing to use INSERT DELAYED.
-
unknown authored
into mysql.com:/home/bk/b20821-mysql-5.1-new-rpl sql/sql_class.cc: Auto merged sql/sql_insert.cc: Auto merged
-
unknown authored
Reverting to old behaviour of writing the query before all rows have been written. mysql-test/r/rpl_row_delayed_ins.result: Result change sql/sql_class.cc: Adding debug message to binlog_query() sql/sql_insert.cc: - Changing write_delayed() to use a LEX_STRING for the query. - Adding query string to class delayed_row. - Removing query string from class delayed_insert. - Adding code to copy query string and delete it when the row is executed. - Logging query at first row instead of after all rows are inserted (reverting to old behaviour). - Flushing the pending row event after all rows have been inserted. This is necessary since binlog_query() is called before all rows instead of after. mysql-test/r/rpl_insert.result: New BitKeeper file ``mysql-test/r/rpl_insert.result'' mysql-test/t/rpl_insert.test: New BitKeeper file ``mysql-test/t/rpl_insert.test''
-
unknown authored
auto_increment breaks binlog": if slave's table had a higher auto_increment counter than master's (even though all rows of the two tables were identical), then in some cases, REPLACE and INSERT ON DUPLICATE KEY UPDATE failed to replicate statement-based (it inserted different values on slave from on master). write_record() contained a "thd->next_insert_id=0" to force an adjustment of thd->next_insert_id after the update or replacement. But it is this assigment introduced indeterminism of the statement on the slave, thus the bug. For ON DUPLICATE, we replace that assignment by a call to handler::adjust_next_insert_id_after_explicit_value() which is deterministic (does not depend on slave table's autoinc counter). For REPLACE, this assignment can simply be removed (as REPLACE can't insert a number larger than thd->next_insert_id). We also move a too early restore_auto_increment() down to when we really know that we can restore the value. mysql-test/r/rpl_insert_id.result: result update, without the bugfix, slave's "3 350" were "4 350". mysql-test/t/rpl_insert_id.test: test for BUG#20188 "REPLACE or ON DUPLICATE KEY UPDATE in auto_increment breaks binlog". There is, in this order: - a test of the bug for the case of REPLACE - a test of basic ON DUPLICATE KEY UPDATE functionality which was not tested before - a test of the bug for the case of ON DUPLICATE KEY UPDATE sql/handler.cc: the adjustment of next_insert_id if inserting a big explicit value, is moved to a separate method to be used elsewhere. sql/handler.h: see handler.cc sql/sql_insert.cc: restore_auto_increment() means "I know I won't use this autogenerated autoincrement value, you are free to reuse it for next row". But we were calling restore_auto_increment() in the case of REPLACE: if write_row() fails inserting the row, we don't know that we won't use the value, as we are going to try again by doing internally an UPDATE of the existing row, or a DELETE of the existing row and then an INSERT. So I move restore_auto_increment() further down, when we know for sure we failed all possibilities for the row. Additionally, in case of REPLACE, we don't need to reset THD::next_insert_id: the value of thd->next_insert_id will be suitable for the next row. In case of ON DUPLICATE KEY UPDATE, resetting thd->next_insert_id is also wrong (breaks statement-based binlog), but cannot simply be removed, as thd->next_insert_id must be adjusted if the explicit value exceeds it. We now do the adjustment by calling handler::adjust_next_insert_id_after_explicit_value() (which, contrary to thd->next_insert_id=0, does not depend on the slave table's autoinc counter, and so is deterministic).
-
- 03 Jul, 2006 5 commits
-
-
unknown authored
into mysql.com:/users/lthalmann/bkroot/mysql-5.0-rpl
-
unknown authored
Disabling 'rpl_openssl'. mysql-test/t/rpl_openssl.test: Disabling 'rpl_openssl'.
-
unknown authored
Enabling rpl_openssl.test for Windows to check that currently it still hangs (because I can't reproduce this on my machine). mysql-test/t/rpl_openssl.test: Enabling rpl_openssl.test for Windows
-
unknown authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.1-merge
-
unknown authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge sql/ha_ndbcluster.cc: Auto merged
-
- 01 Jul, 2006 6 commits
-
-
unknown authored
into dator5.(none):/home/pappa/bug17138 sql/item_sum.cc: Auto merged sql/sql_select.cc: Auto merged sql/sql_update.cc: Auto merged
-
unknown authored
into dator5.(none):/home/pappa/bug17138 mysql-test/r/partition.result: manual merge mysql-test/t/partition.test: manual merge
-
unknown authored
into dator5.(none):/home/pappa/bug20583 mysql-test/r/partition.result: Auto merged mysql-test/t/partition.test: Auto merged sql/ha_partition.cc: Auto merged
-
unknown authored
into dator5.(none):/home/pappa/bug17138 BUILD/compile-pentium-gcov: Auto merged sql/ha_ndbcluster.h: Auto merged sql/handler.h: Auto merged sql/sql_insert.cc: Auto merged sql/sql_select.cc: Auto merged sql/sql_table.cc: Auto merged
-
unknown authored
Last round of review fixes BUILD/compile-pentium-gcov: No change sql/ha_ndbcluster.h: Last round of review changes sql/ha_partition.h: Last round of review changes sql/handler.h: Last round of review changes sql/item_sum.cc: Last round of review changes sql/sql_acl.cc: Last round of review changes sql/sql_insert.cc: Last round of review changes sql/sql_select.cc: Last round of review changes sql/sql_table.cc: Last round of review changes sql/sql_union.cc: Last round of review changes sql/sql_update.cc: Last round of review changes
-
unknown authored
into moonbone.local:/work/merge-5.1
-
- 30 Jun, 2006 9 commits
-
-
unknown authored
mysql-test/t/key.test: Added SHOW CREATE TABLE, which is the proper way to check for table definitions mysql-test/r/key.result: Fixed result after removing wrong bug fix sql/table.cc: Reverted wrong bug fix. The intention with the original code was to show that MySQL treats the first given unique key as a primary key. Clients can use the marked primary key as a real primary key to validate row changes in case of conflicting updates. The ODBC driver (and other drivers) may also use this fact to optimize/check updates and handle conflicts. The marked key also shows what some engines, like InnoDB or NDB, will use as it's internal primary key. For checking if someone has declared a true PRIMARY KEY, one should use 'SHOW CREATE TABLE'
-
unknown authored
into mysql.com:/data0/knielsen/tmp-5.1
-
unknown authored
into mysql.com:/usr/local/mysql/tmp-5.1 scripts/Makefile.am: Auto merged
-
unknown authored
binary disctribution for Falcon. scripts/Makefile.am: Add the make_win_bin_dist script. scripts/make_win_bin_dist: New BitKeeper file ``scripts/make_win_bin_dist''
-
unknown authored
into moonbone.local:/work/merge-5.1 mysql-test/r/ctype_ucs.result: Auto merged mysql-test/r/ctype_utf8.result: Auto merged mysql-test/t/ctype_ucs.test: Auto merged sql/item_cmpfunc.h: Auto merged sql/item_sum.cc: Auto merged sql/opt_range.cc: Auto merged sql/spatial.h: Auto merged sql/sql_select.cc: Auto merged sql/sql_select.h: Auto merged sql/sql_update.cc: Auto merged strings/ctype-mb.c: Auto merged
-
unknown authored
mysql-test/mysql-test-run.sh: Auto merged mysql-test/r/ctype_utf8.result: Auto merged mysql-test/r/func_str.result: Auto merged mysql-test/r/func_time.result: Auto merged mysql-test/r/insert_select.result: Auto merged mysql-test/r/key.result: Auto merged mysql-test/r/myisam.result: Auto merged mysql-test/r/select.result: Auto merged mysql-test/r/sp-prelocking.result: Auto merged mysql-test/r/sp.result: Auto merged mysql-test/r/view_grant.result: Auto merged mysql-test/t/func_time.test: Auto merged mysql-test/t/key.test: Auto merged mysql-test/t/myisam.test: Auto merged mysql-test/t/select.test: Auto merged mysql-test/t/sp-prelocking.test: Auto merged mysql-test/t/sp.test: Auto merged mysql-test/t/view_grant.test: Auto merged mysql-test/valgrind.supp: Auto merged mysys/Makefile.am: Auto merged sql/field.cc: Auto merged sql/field.h: Auto merged sql/ha_ndbcluster.cc: Auto merged sql/item_cmpfunc.cc: Auto merged sql/item_strfunc.cc: Auto merged sql/item_strfunc.h: Auto merged sql/mysql_priv.h: Auto merged sql/mysqld.cc: Auto merged sql/opt_sum.cc: Auto merged sql/slave.cc: Auto merged sql/sp_head.cc: Auto merged sql/sql_base.cc: Auto merged sql/sql_class.cc: Auto merged sql/sql_parse.cc: Auto merged sql/sql_select.cc: Auto merged sql/table.cc: Auto merged storage/ndb/src/kernel/blocks/dbdih/DbdihMain.cpp: Auto merged storage/ndb/src/ndbapi/ndberror.c: Auto merged strings/ctype-mb.c: Auto merged support-files/mysql.spec.sh: Auto merged
-
unknown authored
go from 623 seconds to 11 seconds on AMD64. This is because we have no native atomic implementation on AMD64, so the rwlock-based implementation is used, which is a bit slow. It will be probably be optimized for AMD64 quite soon, but for now this test case will do fewer iterations. unittest/mysys/my_atomic-t.c: 10k iterations instead of 1M no of iterations
-
unknown authored
into mysql.com:/home/cps/mysql/trees/5.1-team
-
unknown authored
mysys/my_pread.c: don't set errno without a real error
-