- 16 Dec, 2009 1 commit
-
-
Mats Kindahl authored
Fixes to get it to compile on MacOSX.
-
- 15 Dec, 2009 1 commit
-
-
Mats Kindahl authored
for InnoDB The class Field_bit_as_char stores the metadata for the field incorrecly because bytes_in_rec and bit_len are set to (field_length + 7 ) / 8 and 0 respectively, while Field_bit has the correct values field_length / 8 and field_length % 8. Solved the problem by re-computing the values for the metadata based on the field_length instead of using the bytes_in_rec and bit_len variables. To handle compatibility with old server, a table map flag was added to indicate that the bit computation is exact. If the flag is clear, the slave computes the number of bytes required to store the bit field and compares that instead, effectively allowing replication *without conversion* from any field length that require the same number of bytes to store.
-
- 14 Dec, 2009 2 commits
-
-
Mats Kindahl authored
Fixing minor error when printing SQL types from master and cleaning some code. Updating result files.
-
Mats Kindahl authored
Row-based replication requires the types of columns on the master and slave to be approximately the same (some safe conversions between strings are allowed), but does not allow safe conversions between fields of similar types such as TINYINT and INT. This patch implement type conversions between similar fields on the master and slave. The conversions are controlled using a new variable SLAVE_TYPE_CONVERSIONS of type SET('ALL_LOSSY','ALL_NON_LOSSY'). Non-lossy conversions are any conversions that do not run the risk of losing any information, while lossy conversions can potentially truncate the value. The column definitions are checked to decide if the conversion is acceptable. If neither conversion is enabled, it is required that the definitions of the columns are identical on master and slave. Conversion is done by creating an internal conversion table, unpacking the master data into it, and then copy the data to the real table on the slave.
-
- 21 Oct, 2009 1 commit
-
-
Bjorn Munch authored
-
- 20 Oct, 2009 1 commit
-
-
Bjorn Munch authored
-
- 19 Oct, 2009 2 commits
-
-
Bjorn Munch authored
Knowledge of no SSL support is not used Skip tests the same way e.g. innodb tests are Does not refer to have_ssl_communication.inc, will add this when merging to 6.0-codebase
-
Bjorn Munch authored
-
- 18 Oct, 2009 1 commit
-
-
Bjorn Munch authored
Don't print entire log, but use extract_server_log() introduced by 46007
-
- 17 Oct, 2009 1 commit
-
-
Bjorn Munch authored
Test batches may be terminated too early Avoid counting exp-fail tests
-
- 16 Oct, 2009 10 commits
-
-
Bjorn Munch authored
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Joerg Bruehe authored
Use "#ifdef", not plain "#if".
-
Joerg Bruehe authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 15 Oct, 2009 8 commits
-
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Alexey Kopytov authored
-
Sergey Vojtovich authored
-
- 14 Oct, 2009 12 commits
-
-
Jorgen Loland authored
-
Jorgen Loland authored
Temporary tables may set join->group to 0 even though there is grouping. Also need to test if sum_func_count>0 when JOIN::exec() decides whether to present results in a grouped manner.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
He Zhenxing authored
-
Jorgen Loland authored
columns without where/group Simple SELECT with implicit grouping used to return many rows if the query was ordered by the aggregated column in the SELECT list. This was incorrect because queries with implicit grouping should only return a single record. The problem was that when JOIN:exec() decided if execution needed to handle grouping, it was assumed that sum_func_count==0 meant that there were no aggregate functions in the query. This assumption was not correct in JOIN::exec() because the aggregate functions might have been optimized away during JOIN::optimize(). The reason why queries without ordering behaved correctly was that sum_func_count is only recalculated if the optimizer chooses to use temporary tables (which it does in the ordered case). Hence, non-ordered queries were correctly treated as grouped. The fix for this bug was to remove the assumption that sum_func_count==0 means that there is no need for grouping. This was done by introducing variable "bool implicit_grouping" in the JOIN object.
-
sunanda.menon@sun.com authored
-
Bjorn Munch authored
Difficult to debug due to lacking report This does not solve the real issue, but extracts server log when it happens Forst commit was incomplete, didn't cover all cases
-