An error occurred fetching the project authors.
- 03 Jul, 2009 2 commits
-
-
Alexey Kopytov authored
-
Alexey Kopytov authored
Using DECIMAL constants with more than 65 digits in CREATE TABLE ... SELECT led to bogus errors in release builds or assertion failures in debug builds. The problem was in inconsistency in how DECIMAL constants and fields are handled internally. We allow arbitrarily long DECIMAL constants, whereas DECIMAL(M,D) columns are limited to M<=65 and D<=30. my_decimal_precision_to_length() was used in both Item and Field code and truncated precision to DECIMAL_MAX_PRECISION when calculating value length without adjusting precision and decimals. As a result, a DECIMAL constant with more than 65 digits ended up having length less than precision or decimals which led to assertion failures. Fixed by modifying my_decimal_precision_to_length() so that precision is truncated to DECIMAL_MAX_PRECISION only for Field object which is indicated by the new 'truncate' parameter. Another inconsistency fixed by this patch is how DECIMAL constants and expressions are handled for CREATE ... SELECT. create_tmp_field_from_item() (which is used for constants) was changed as a part of the bugfix for bug #24907 to handle long DECIMAL constants gracefully. Item_func::tmp_table_field() (which is used for expressions) on the other hand was still using a simplistic approach when creating a Field_new_decimal from a DECIMAL expression. mysql-test/r/type_newdecimal.result: Added a test case for bug #45262. mysql-test/t/type_newdecimal.test: Added a test case for bug #45262. sql/item.cc: Use the new 'truncate' parameter in my_decimal_precision_to_length(). sql/item_cmpfunc.cc: Use the new 'truncate' parameter in my_decimal_precision_to_length(). sql/item_func.cc: 1. Use the new 'truncate' parameter in my_decimal_precision_to_length(). 2. Do not truncate decimal precision to DECIMAL_MAX_PRECISION for additive expressions involving long DECIMAL constants. 3. Fixed an incosistency in how DECIMAL constants and expressions are handled for CREATE ... SELECT. sql/item_func.h: Use the new 'truncate' parameter in my_decimal_precision_to_length(). sql/item_sum.cc: Use the new 'truncate' parameter in my_decimal_precision_to_length(). sql/my_decimal.h: Do not truncate precision to DECIMAL_MAX_PRECISION when calculating length in my_decimal_precision_to_length() if 'truncate' parameter is FALSE. sql/sql_select.cc: 1. Use the new 'truncate' parameter in my_decimal_precision_to_length(). 2. Use a more correct logic when adjusting value's length.
-
- 23 Jun, 2009 1 commit
-
-
Andrei Elkin authored
The reason for the crash was rotate_relay_log (mi=0x0) did not verify the passed value of active_mi. There are more cases where active_mi is supposed to be non-zero e.g change_master(), stop_slave(), and it's reasonable to protect from a similar crash all of them with common fixes. Fixed with spliting end_slave() in slave threads release and slave data clean-up parts (a new close_active_mi()). The new function is invoked at the very end of close_connections() so that all users of active_mi are proven to have left. sql/mysqld.cc: added the 2nd part (data) of the slave's clean up. sql/slave.cc: end_slave() is split in two part to release the slave threads and the remained resources separately. The new close_active_mi() should be called after all possible users ofactive_mi has left, i.e at the very end of close_connections(). sql/slave.h: interface to the new end_active_mi() function is added.
-
- 22 Jun, 2009 9 commits
-
-
Martin Hansson authored
-
Martin Hansson authored
Bug#44653: Server crash noticed when executing random queries with partitions. When opening a table, it is imperative that the flag TABLE::auto_increment_field_not_null be false. But if an error occured during the creation of a table (e.g. the table exists already) with an auto_increment column and a BEFORE trigger that used the INSERT ... SELECT construct, the flag was not reset until after error checking. Thus if an error occured, select_insert::send_data() returned immediately and it was not reset (see * in pseudocode below). Crash happened if the table was opened again. Fixed by resetting the flag after error checking. nested-loops_join(): for each row in SELECT table { select_insert::send_data(): if a values is supplied for AUTO_INCREMENT column table->auto_increment_field_not_null= TRUE else table->auto_increment_field_not_null= FALSE if (error) return 1; * if (table->auto_increment_field_not_null == FALSE) ... table->auto_increment_field_not_null == FALSE } <-- table returned to table cache and later retrieved by open_table: open_table(): assert(table->auto_increment_field_not_null) mysql-test/r/trigger.result: Bug#44653: Test result mysql-test/t/trigger.test: Bug#44653: Test case sql/sql_insert.cc: Bug#44653: Fix: Make sure to unset this field before returning in case of error
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
V Narayanan authored
-
Georgi Kodinov authored
-
Satya B authored
1. BUG#45357 - 5.1.35 crashes with Failing assertion: index->type & DICT_CLUSTERED 2. Also fixes the compilation problem when the flag -DUNIV_MUST_NOT_INLINE Detailed revision comments: r5340 | marko | 2009-06-17 12:11:49 +0300 (Wed, 17 Jun 2009) | 4 lines branches/5.1: row_unlock_for_mysql(): When the clustered index is unknown, refuse to unlock the record. (Bug #45357, caused by the fix of Bug #39320). rb://132 approved by Sunny Bains. r5339 | marko | 2009-06-17 11:01:37 +0300 (Wed, 17 Jun 2009) | 2 lines branches/5.1: Add missing #include "mtr0log.h" so that the code compiles with -DUNIV_MUST_NOT_INLINE.
-
V Narayanan authored
The merge from http://lists.mysql.com/commits/76678 caused the growth_size parameter to the my_init_dynamic_array function to be ignored. This patch corrects the problem. mysys/hash.c: Bug#43572 Handle failures from hash_init Replacing the last parameter to my_init_dynamic_array with growth_size.
-
- 19 Jun, 2009 15 commits
-
-
Matthias Leich authored
-
Matthias Leich authored
-
Matthias Leich authored
-
Matthias Leich authored
-
Georgi Kodinov authored
-
Matthias Leich authored
-
Matthias Leich authored
Details: - Limit the queries to character sets and collations which are most probably available in all build types. But try to preserve the intention of the tests. - Remove the variants adjusted to some build types. Note: 1. The results of the review by Bar are included. 2. I am not able to check the correctness of this patch on any existing build type and any MySQL version. So it could happen that the new test fails somewhere.
-
Georgi Kodinov authored
occasionally. mysql_multi can call mysqld_safe. In doing this it's not changing the current working directory. This may cause confusion in the case where mysqld_multi is handling instances of servers of different versions and the current working directory is the installation directory of one of these servers. Fixed by enhancing the meaning of basedir in [mysqldN] sections of mysqld_multi. If specified, mysqld_multi will change the current working directory to the basedir directory before starting the server in mysqld_multi ... start ... and then change it back to what it was. scripts/mysqld_multi.sh: Bug #36654: optionally preserve, change and restore the cwd when starting server instances
-
V Narayanan authored
-
V Narayanan authored
Failure to allocate memory for the hash->array element, caused hash_init to return without initializing the other members of the hash. Thus although the dynamic array buffer may be allocated at a later point in the code, the incompletely initialized hash caused fatal failures. This patch moves the initialization of the other members of the hash above the array allocation, so that the usage of this hash will not result in fatal failures. include/hash.h: Bug#43572 Handle failures from hash_init hash_inited is used to verify that the hash is valid. After the change induced by the current patch hash->array.buffer !=0 is not a valid check for this condition, since, the dynamic array can be allocated even at a later time. Bootstrap SQL script is setting some variables, which are actually not set due to this hash_inited issue. Thus we get empty grant tables. A better way to check if the hash is valid is to verify that hash->blength is greater than 0. mysys/hash.c: Bug#43572 Handle failures from hash_init Move the initialization of the other members of the hash above the array allocation, so that the usage of this hash will not result in fatal failures.
-
Alfranio Correia authored
-
Sergey Glukhov authored
-
Staale Smedseng authored
-
Staale Smedseng authored
Inconsistent behavior of session variable max_allowed_packet (and net_buffer_length); only assignment to the global variable has any effect, without this being obvious to the user. The patch for Bug#22891 is backported to 5.0, making the two session variables read-only. As this is a backport to GA software, the error used when trying to assign to the read- only variable is ER_UNKNOWN_ERROR. The error message is the same as in 5.1+. mysql-test/t/variables.test: Tests are changed to account for the new semantics, and assignment to the read-only variables is added to test the emission of the correct error message. sql/set_var.cc: Both max_allowed_packet and net_buffer_length are changed to be of type sys_var_thd_ulong_session_readonly. ER_UNKNOWN_ERROR is used to indicate an attempt to assign to an instance of a read-only variable. sql/set_var.h: Class sys_var_thd_ulong_session_readonly is added.
-
Sergey Glukhov authored
The problem: described in the bug report. The fix: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used client/mysql.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/ha_ndbcluster.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/ha_ndbcluster_binlog.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/handler.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/log.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/mysqld.cc: removed unnecessary line sql/parse_file.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/sql_acl.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/sql_base.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/sql_db.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/sql_delete.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/sql_partition.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/sql_rename.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/sql_show.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/sql_table.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function sql/sql_view.cc: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used as argument for strxnmov function
-
- 18 Jun, 2009 7 commits
-
-
Davi Arnaut authored
The problem was that a pthread.h header used by gcc did not declare the pthread_setscheprio, yet the function is implemented by the function is implemented, causing a autoconf check to pass and compilation with C++ to fail. The solution is to add a autoconf check to ensure that the function is properly declared. configure.in: Check that the pthread_setschedprio is declared.
-
Alfranio Correia authored
-
Alfranio Correia authored
-
Alfranio Correia authored
-
Alfranio Correia authored
-
Alfranio Correia authored
Large transactions and statements may corrupt the binary log if the size of the cache, which is set by the max_binlog_cache_size, is not enough to store the the changes. In a nutshell, to fix the bug, we save the position of the next character in the cache before starting processing a statement. If there is a problem, we simply restore the position thus removing any effect of the statement from the cache. Unfortunately, to avoid corrupting the binary log, we may end up loosing changes on non-transactional tables if they do not fit in the cache. In such cases, we store an Incident_log_event in order to stop the slave and alert users that some changes were not logged. Precisely, for every non-transactional changes that do not fit into the cache, we do the following: a) the statement is *not* logged b) an incident event is logged after committing/rolling back the transaction, if any. Note that if a failure happens before writing the incident event to the binary log, the slave will not stop and the master will not have reported any error. c) its respective statement gives an error For transactional changes that do not fit into the cache, we do the following: a) the statement is *not* logged b) its respective statement gives an error To work properly, this patch requires two additional things. Firstly, callers to MYSQL_BIN_LOG::write and THD::binlog_query must handle any error returned and take the appropriate actions such as undoing the effects of a statement. We already changed some calls in the sql_insert.cc, sql_update.cc and sql_insert.cc modules but the remaining calls spread all over the code should be handled in BUG#37148. Secondly, statements must be either classified as DDL or DML because DDLs that do not get into the cache must generate an incident event since they cannot be rolled back.
-
Martin Hansson authored
-
- 17 Jun, 2009 6 commits
-
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Staale Smedseng authored
-