An error occurred fetching the project authors.
- 28 Feb, 2007 1 commit
-
-
bar@mysql.com authored
This patch fixes problem that LOAD DATA could use different character sets when loading files on master and on slave sides: - Adding replication of thd->variables.collation_database - Adding optional character set clause into LOAD DATA Note, the second way, with explicit CHARACTER SET clause should be the recommended way to load data using an alternative character set. The old way, using "SET @@character_set_database=xxx" should be gradually depricated.
-
- 15 Feb, 2007 2 commits
-
-
guilhem@gbichot3.local authored
When opening/creating the transaction coordinator's log, if binlog is used, the tc log is the binlog so we use the binlog's name; otherwise we use the mmap-based log, named after the mandatory argument of the --log-tc option (meant for that).
-
guilhem@gbichot3.local authored
duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong)), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: if (statement-based) binlogging is on, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. Note: it is not possible to test BUG#25507 in 5.0 (requires mysqlslap), so it is tested only in the changeset for 5.1. However, BUG#26116 is tested here, and the fix for BUG#25507 is the same code change.
-
- 08 Feb, 2007 2 commits
-
-
guilhem@gbichot3.local authored
into gbichot3.local:/home/mysql_src/mysql-5.0-rpl-24432
-
guilhem@gbichot3.local authored
"INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values". When in an INSERT ON DUPLICATE KEY UPDATE, using an autoincrement column, we inserted some autogenerated values and also updated some rows, some autogenerated values were not used (for example, even if 10 was the largest autoinc value in the table at the start of the statement, 12 could be the first autogenerated value inserted by the statement, instead of 11). One autogenerated value was lost per updated row. Led to exhausting the range of the autoincrement column faster. Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12. This bug breaks replication from a pre-5.0.24 master. But the present bugfix, as it makes INSERT ON DUP KEY UPDATE behave like pre-5.0.24, breaks replication from a [5.0.24,5.0.34] master to a fixed (5.0.36) slave! To warn users against this when they upgrade their slave, as agreed with the support team, we add code for a fixed slave to detect that it is connected to a buggy master in a situation (INSERT ON DUP KEY UPDATE into autoinc column) likely to break replication, in which case it cannot replicate so stops and prints a message to the slave's error log and to SHOW SLAVE STATUS. For 5.0.36->[5.0.24,5.0.34] replication we cannot warn as master does not know the slave's version (but we always recommended to users to have slave at least as new as master). As agreed with support, I'll also ask for an alert to be put into the MySQL Network Monitoring and Advisory Service.
-
- 24 Jan, 2007 1 commit
-
-
bar@mysql.com authored
Problem: "Data truncated" warning was incorrectly generated when storing a Japanese character encoded in utf8 into a cp932 column. Reason: Incorrect wrong warning condition compared the original length of the character in bytes (which is 3 in utf8) to the converted length of the character in bytes (which is 2 in cp932). Fix: use "how many bytes were scanned from input" instead of "how many bytes were put to the column" in the condition.
-
- 18 Jan, 2007 2 commits
-
-
cbell/Chuck@mysql_cab_desk. authored
into mysql_cab_desk.:C:/source/c++/mysql-5.0_BUG_21490
-
cbell/Chuck@mysql_cab_desk. authored
This patch deprecates the replication startup options in the configuration file and on the command line. The options deprecated include: MASTER_HOST, MASTER_USER, MASTER_PASSWORD, MASTER_PORT, MASTER_CONNECT_RETRY, MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY, and MASTER_SSL_CIPHER The code is designed to print the warning message once.
-
- 17 Jan, 2007 7 commits
-
-
into mysql.com:/nfsdisk1/lars/MERGE/mysql-5.0-merge
-
into mysql.com:/nfsdisk1/lars/MERGE/mysql-5.0-merge
-
into mysql.com:/nfsdisk1/lars/MERGE/mysql-4.1-merge
-
kostja@bodhi.local authored
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-debug-max
-
kostja@bodhi.local authored
by the patch for Bug#4968
-
kostja@bodhi.local authored
-
- 16 Jan, 2007 3 commits
-
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.local authored
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg20390-2
-
- 15 Jan, 2007 11 commits
-
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.0-6298
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.local authored
-
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg20390-2
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-4968-to-push
-
kostja@bodhi.local authored
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-4.1-4968-to-push
-
dlenev@mockturtle.local authored
of untouched rows in full table scans". SELECT ... FOR UPDATE/LOCK IN SHARE MODE statements as well as UPDATE/DELETE statements which were executed using full table scan were not releasing locks on rows which didn't satisfy WHERE condition. This bug surfaced in 5.0 and affected NDB tables. (InnoDB tables intentionally don't support such unlocking in default mode). This problem occured because code implementing join didn't call handler::unlock_row() for rows which didn't satisfy part of condition attached to this particular table/level of nested loop. So we solve the problem adding this call. Note that we already had this call in place in 4.1 but it was lost (actually not quite correctly placed) when we have introduced nested joins. Also note that additional QA should be requested once this patch is pushed as interaction between handler::unlock_row() and many recent MySQL features such as subqueries, unions, views is not tested enough.
-
- 12 Jan, 2007 11 commits
-
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-4.1-runtime
-
joerg@trift2. authored
into trift2.:/MySQL/M41/mysql-4.1
-
into mysql.com:/nfsdisk1/lars/MERGE/mysql-5.0-merge
-
into mysql.com:/nfsdisk1/lars/MERGE/mysql-4.1-merge
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0
-
joerg@trift2. authored
into trift2.:/MySQL/M41/push-4.1
-
mmj@tiger.mmj.dk authored
Patch from Paul DuBois for better help messages
-