- 27 Jul, 2006 1 commit
-
-
- 26 Jul, 2006 3 commits
-
-
aivanov@mysql.com authored
-
aivanov@mysql.com authored
into mysql.com:/home/alexi/innodb/mysql-5.0-work Null merge.
-
aivanov@mysql.com authored
-
- 11 Jul, 2006 1 commit
-
-
mkindahl@dl145k.mysql.com authored
into dl145k.mysql.com:/data0/mkindahl/bk/MERGE/mysql-5.0-merge
-
- 10 Jul, 2006 4 commits
-
-
guilhem@gbichot3.local authored
into gbichot3.local:/home/mysql_src/mysql-5.0
-
pekka@orca.ndb.mysql.com authored
-
pekka@orca.ndb.mysql.com authored
-
into dsl-hkigw8-feb1fb00-100.dhcp.inet.fi:/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/5.0/20919_temp_nlog
-
- 09 Jul, 2006 1 commit
-
-
closing temp tables through end_thread had a flaw in binlog-off branch of close_temporary_tables where next table to close was reset via table->next for (table= thd->temporary_tables; table; table= table->next) which was wrong since the current table instance got destoyed at close_temporary(table, 1); The fix adapts binlog-on branch method to engage the loop's internal 'next' variable which holds table->next prior table's destoying.
-
- 06 Jul, 2006 3 commits
-
-
guilhem@gbichot3.local authored
into gbichot3.local:/home/mysql_src/mysql-5.0
-
guilhem@gbichot3.local authored
into gbichot3.local:/home/mysql_src/mysql-5.0
-
guilhem@mysql.com 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.
-
- 05 Jul, 2006 1 commit
-
-
guilhem@mysql.com 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.
-
- 03 Jul, 2006 4 commits
-
-
lars@mysql.com authored
into mysql.com:/users/lthalmann/bkroot/mysql-5.0-rpl
-
aivanov@mysql.com authored
Disabling 'rpl_openssl'.
-
aivanov@mysql.com authored
Enabling rpl_openssl.test for Windows to check that currently it still hangs (because I can't reproduce this on my machine).
-
lars@mysql.com authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
- 29 Jun, 2006 4 commits
-
-
tomas@poseidon.ndb.mysql.com authored
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-5.0
-
tomas@poseidon.ndb.mysql.com authored
-
tomas@poseidon.ndb.mysql.com authored
+ adopted signal to be as close as possible to 5.1...
-
- 28 Jun, 2006 8 commits
-
-
lars@mysql.com authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
knielsen@mysql.com authored
In the Windows build files, the "Max nt" configuration for some reason had the mysql_client_test project disabled. Enable it.
-
lars@mysql.com authored
-
knielsen@mysql.com authored
Improved definition of mysys configuration for -nt builds.
-
knielsen@mysql.com authored
Make sure for the mysys project that __NT__ is defined in *nt solution configurations (but not in other configurations).
-
aivanov@mysql.com authored
-
aivanov@mysql.com authored
into mysql.com:/home/alexi/bugs/mysql-5.0-19208
-
aivanov@mysql.com authored
and BUG#19208 "Test 'rpl000017' hangs on Windows". Both bugs are caused by attempting to delete an opened file and to create immediatedly a new one with the same name. On Windows it can be supported only on NT-platforms (by using FILE_SHARE_DELETE mode and with renaming the file before deletion). Because deleting not-closed files is not supported on all platforms (e.g. Win 98|ME) this is to be considered harmful and should be eliminated by a "code redesign".
-
- 27 Jun, 2006 2 commits
-
-
tomas@poseidon.ndb.mysql.com authored
- correction of previous patch
-
tomas@poseidon.ndb.mysql.com authored
- make sure to allocate just enough pages in the fragments by using the actual row count from the backup, to avoid over allocation of pages to fragments, and thus avoid the bug
-
- 26 Jun, 2006 1 commit
-
-
lars@mysql.com authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
- 24 Jun, 2006 1 commit
-
-
knielsen@mysql.com authored
Sometimes the helper connection (that is watching for the main connection to time out) would itself time out first, causing the test to fail.
-
- 21 Jun, 2006 6 commits
-
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main
-
tomas@poseidon.ndb.mysql.com authored
-
lars@mysql.com authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main
-
mskold@mysql.com authored
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main
-