An error occurred fetching the project authors.
- 01 Jul, 2006 1 commit
-
-
dlenev@mysql.com authored
NDB table". SQL-layer was not marking fields which were used in triggers as such. As result these fields were not always properly retrieved/stored by handler layer. So one might got wrong values or lost changes in triggers for NDB, Federated and possibly InnoDB tables. This fix solves the problem by marking fields used in triggers appropriately. Also this patch contains the following cleanup of ha_ndbcluster code: We no longer rely on reading LEX::sql_command value in handler in order to determine if we can enable optimization which allows us to handle REPLACE statement in more efficient way by doing replaces directly in write_row() method without reporting error to SQL-layer. Instead we rely on SQL-layer informing us whether this optimization applicable by calling handler::extra() method with HA_EXTRA_WRITE_CAN_REPLACE flag. As result we no longer apply this optimzation in cases when it should not be used (e.g. if we have on delete triggers on table) and use in some additional cases when it is applicable (e.g. for LOAD DATA REPLACE). Finally this patch includes fix for bug#20728 "REPLACE does not work correctly for NDB table with PK and unique index". This was yet another problem which was caused by improper field mark-up. During row replacement fields which weren't explicity used in REPLACE statement were not marked as fields to be saved (updated) so they have retained values from old row version. The fix is to mark all table fields as set for REPLACE statement. Note that in 5.1 we already solve this problem by notifying handler that it should save values from all fields only in case when real replacement happens.
-
- 26 Jun, 2006 2 commits
-
-
konstantin@mysql.com authored
Bug#19022 "Memory bug when switching db during trigger execution" Bug#17199 "Problem when view calls function from another database." Bug#18444 "Fully qualified stored function names don't work correctly in SELECT statements" Documentation note: this patch introduces a change in behaviour of prepared statements. This patch adds a few new invariants with regard to how THD::db should be used. These invariants should be preserved in future: - one should never refer to THD::db by pointer and always make a deep copy (strmake, strdup) - one should never compare two databases by pointer, but use strncmp or my_strncasecmp - TABLE_LIST object table->db should be always initialized in the parser or by creator of the object. For prepared statements it means that if the current database is changed after a statement is prepared, the database that was current at prepare remains active. This also means that you can not prepare a statement that implicitly refers to the current database if the latter is not set. This is not documented, and therefore needs documentation. This is NOT a change in behavior for almost all SQL statements except: - ALTER TABLE t1 RENAME t2 - OPTIMIZE TABLE t1 - ANALYZE TABLE t1 - TRUNCATE TABLE t1 -- until this patch t1 or t2 could be evaluated at the first execution of prepared statement. CURRENT_DATABASE() still works OK and is evaluated at every execution of prepared statement. Note, that in stored routines this is not an issue as the default database is the database of the stored procedure and "use" statement is prohibited in stored routines. This patch makes obsolete the use of check_db_used (it was never used in the old code too) and all other places that check for table->db and assign it from THD::db if it's NULL, except the parser. How this patch was created: THD::{db,db_length} were replaced with a LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were manually checked and: - if the place uses thd->db by pointer, it was fixed to make a deep copy - if a place compared two db pointers, it was fixed to compare them by value (via strcmp/my_strcasecmp, whatever was approproate) Then this intermediate patch was used to write a smaller patch that does the same thing but without a rename. TODO in 5.1: - remove check_db_used - deploy THD::set_db in mysql_change_db See also comments to individual files.
-
ingo@mysql.com authored
Addendum fixes after changing the condition variable for the global read lock. The stress test suite revealed some deadlocks. Some were related to the new condition variable (COND_global_read_lock) and some were general problems with the global read lock. It is now necessary to signal COND_global_read_lock whenever COND_refresh is signalled. We need to wait for the release of a global read lock if one is set before every operation that requires a write lock. But we must not wait if we have locked tables by LOCK TABLES. After setting a global read lock a thread waits until all write locks are released.
-
- 23 Jun, 2006 1 commit
-
-
iggy@mysql.com authored
-
- 01 Jun, 2006 1 commit
-
-
svoj@may.pils.ru authored
ALTER TABLE crashes Executing fast alter table (one that doesn't need to copy data) on tables created by mysql versions prior to 4.0.25 could result in posterior server crash when accessing these tables. There was a bug prior to mysql-4.0.25. Number of null fields was calculated incorrectly. As a result frm and data files gets out of sync after fast alter table. There is no way to determine by which mysql version (in 4.0 and 4.1 branches) table was created, thus we disable fast alter table for all tables created by mysql versions prior to 5.0 branch. See BUG#6236.
-
- 30 May, 2006 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
Bug#18282 "INFORMATION_SCHEMA.TABLES provides inconsistent info about invalid views" This bug caused crashes or resulted in wrong data being returned when one tried to obtain information from I_S tables about views using stored functions. It was caused by the fact that we were using LEX representing statement which were doing select from I_S tables as active LEX when contents of I_S table were built. So state of this LEX both affected and was affected by open_tables() calls which happened during this process. This resulted in wrong behavior and in violations of some of invariants which caused crashes. This fix tries to solve this problem by properly saving/resetting and restoring part of LEX which affects and is affected by the process of opening tables and views in get_all_tables() routine. To simplify things we separated this part of LEX in a new class and made LEX its descendant.
-
- 16 May, 2006 1 commit
-
-
svoj@april.(none) authored
frm and data files for tables created by earlier MySQL versions becomes out of sync after certain ALTER TABLE statements: - One that changes column default value; - One that changes table comment; - One that changes table password. As a result one can expirience either server crash or data corruption/loss. This fix ensures that running ALTER TABLE on tables created by earlier MySQL versions recreates data files.
-
- 09 May, 2006 2 commits
-
-
acurtis@xiphis.org authored
"alter table from MyISAM to MERGE lost data without errors and warnings" Add new handlerton flag which prevent user from altering table storage engine to storage engines which would lose data. Both 'blackhole' and 'merge' are marked with the new flag. Tests included.
-
dlenev@mysql.com authored
or implicitly uses stored function gives "Table not locked" error' CREATE TABLE ... SELECT ... statement which was explicitly or implicitly (through view) using stored function gave "Table not locked" error. The actual bug resides in the current locking scheme of CREATE TABLE SELECT code, which first opens and locks tables of the SELECT statement itself, and then, having SELECT tables locked, creates the .FRM, opens the .FRM and acquires lock on it. This scheme opens a possibility for a deadlock, which was present and ignored since version 3.23 or earlier. This scheme also conflicts with the invariant of the prelocking algorithm -- no table can be open and locked while there are tables locked in prelocked mode. The patch makes an exception for this invariant when doing CREATE TABLE ... SELECT, thus extending the possibility of a deadlock to the prelocked mode. We can't supply a better fix in 5.0.
-
- 03 May, 2006 1 commit
-
-
holyfoot@deer.(none) authored
-
- 28 Apr, 2006 1 commit
-
-
elliot@mysql.com authored
Now test for NULLness the pointers returned from objects created from the default value. Pushing patch on behalf of cmiller.
-
- 25 Apr, 2006 1 commit
-
-
ramil@mysql.com authored
-
- 12 Apr, 2006 1 commit
-
-
holyfoot@deer.(none) authored
-
- 30 Mar, 2006 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
-
- 29 Mar, 2006 2 commits
-
-
evgen@moonbone.local authored
The GROUP_CONCAT uses its own temporary table. When ROLLUP is present it creates the second copy of Item_func_group_concat. This copy receives the same list of arguments that original group_concat does. When the copy is set up the result_fields of functions from the argument list are reset to the temporary table of this copy. As a result of this action data from functions flow directly to the ROLLUP copy and the original group_concat functions shows wrong result. Since queries with COUNT(DISTINCT ...) use temporary tables to store the results the COUNT function they are also affected by this bug. The idea of the fix is to copy content of the result_field for the function under GROUP_CONCAT/COUNT from the first temporary table to the second one, rather than setting result_field to point to the second temporary table. To achieve this goal force_copy_fields flag is added to Item_func_group_concat and Item_sum_count_distinct classes. This flag is initialized to 0 and set to 1 into the make_unique() member function of both classes. To the TMP_TABLE_PARAM structure is modified to include the similar flag as well. The create_tmp_table() function passes that flag to create_tmp_field(). When the flag is set the create_tmp_field() function will set result_field as a source field and will not reset that result field to newly created field for Item_func_result_field and its descendants. Due to this there will be created copy func to copy data from old result_field to newly created field.
-
gluh@eagle.intranet.mysql.r18.ru authored
disallow the use of comma in SET members
-
- 24 Mar, 2006 2 commits
-
-
dlenev@mysql.com authored
tables corrupt triggers". It turned out that we also have relied at certain places that (new_table != table_name) were always true on Windows and for transactional tables. Since our fix for the bug brakes this assumption we have to add new flag to pass this information around. This code needs to be refactored but I dare not to do this in 5.0.
-
dlenev@mysql.com authored
triggers". Applying ALTER/OPTIMIZE/REPAIR TABLE statements to transactional table or to table of any type on Windows caused disappearance of its triggers. Bug was introduced in 5.0.19 by my fix for bug #13525 "Rename table does not keep info of triggers" (see comment for sql_table.cc for more info). .
-
- 24 Feb, 2006 1 commit
-
-
dlenev@mysql.com authored
Let us transfer triggers associated with table when we rename it (but only if we are not changing database to which table belongs, in the latter case we will emit error).
-
- 21 Feb, 2006 2 commits
-
-
konstantin@mysql.com authored
column is increasing when table is recreated with PS/SP": make use of create_field::char_length more consistent in the code. Reinit create_field::length from create_field::char_length for every execution of a prepared statement (actually fixes the bug).
-
evgen@moonbone.local authored
When a too long field is used for a key, only a prefix part of the field is used. Length is reduced to the max key length allowed for storage. But if the field have a multibyte charset it is possible to break multibyte char sequence. This leads to the failed assertion in the innodb code and server crash when a record is inserted. The make_prepare_table() now aligns truncated key length to the boundary of multibyte char.
-
- 17 Feb, 2006 1 commit
-
-
holyfoot@deer.(none) authored
necessary implementation in the server mysql_upgrade script added
-
- 01 Feb, 2006 1 commit
-
-
ingo@mysql.com authored
There are (at least) two implementations of the checksum computation. One is in MyISAM for the quick checksum. It is executed on every row change. The other is in the SQL layer for the extended checksum. It retrieves all rows of a table via the respective storage engine. In former MySQL versions varchars were stored with their maximum length, but now with their real length similar to blobs. This change had been forgotten to take care of in the extended checksum calculation. Hence too much data was checksumed. In MyISAM this change had been taken care of already. Only the real data is included in the checksum. I changed mysql_checksum_table() so that it uses the length information of true varchar fields instead of the field length like in former varchar implementations.
-
- 13 Jan, 2006 1 commit
-
-
svoj@april.(none) authored
Allow fulltext index on VARCHAR columns longer than max key length.
-
- 10 Dec, 2005 1 commit
-
-
holyfoot@deer.(none) authored
-
- 05 Dec, 2005 1 commit
-
-
serg@serg.mylan authored
-
- 03 Dec, 2005 1 commit
-
-
serg@serg.mylan authored
it's about mysql_admin_commands not being reexecution-safe (and CHECK still isn't)
-
- 25 Nov, 2005 2 commits
-
-
konstantin@mysql.com authored
-
konstantin@mysql.com authored
CREATE TABLE and PS/SP": make sure that 'typelib' object for ENUM values and 'Item_string' object for DEFAULT clause are created in the statement memory root.
-
- 24 Nov, 2005 1 commit
-
-
holyfoot@deer.(none) authored
-
- 20 Nov, 2005 1 commit
-
-
bell@sanja.is.com.ua authored
Bad examples of usage of a string with its length fixed. The incorrect length in the trigger file configuration descriptor fixed (BUG#14090). A hook for unknown keys added to the parser to support old .TRG files.
-
- 15 Nov, 2005 1 commit
-
-
ingo@mysql.com authored
Version for 5.0. It fixes three problems: 1. The cause of the bug was that we did not check the table version for the HANDLER ... READ commands. We did not notice when a table was replaced by a new one. This can happen during ALTER TABLE, REPAIR TABLE, and OPTIMIZE TABLE (there might be more cases). I call the fix for this problem "the primary bug fix". 2. mysql_ha_flush() was not always called with a locked LOCK_open. Though the function comment clearly said it must. I changed the code so that the locking is done when required. I call the fix for this problem "the secondary fix". 3. In 5.0 (not in 4.1 or 4.0) DROP TABLE had a possible deadlock flaw in concur with FLUSH TABLES WITH READ LOCK. I call the fix for this problem "the 5.0 addendum fix".
-
- 09 Nov, 2005 1 commit
-
-
sergefp@mysql.com authored
-
- 07 Nov, 2005 1 commit
-
-
sergefp@mysql.com authored
when calculating table->null_fields.
-
- 06 Nov, 2005 1 commit
-
-
igor@rurik.mysql.com authored
-
- 03 Nov, 2005 4 commits
-
-
ingo@mysql.com authored
Version for 4.0. It fixes two problems: 1. The cause of the bug was that we did not check the table version for the HANDLER ... READ commands. We did not notice when a table was replaced by a new one. This can happen during ALTER TABLE, REPAIR TABLE, and OPTIMIZE TABLE (there might be more cases). I call the fix for this problem "the primary bug fix". 2. mysql_ha_flush() was not always called with a locked LOCK_open. Though the function comment clearly said it must. I changed the code so that the locking is done when required. I call the fix for this problem "the secondary fix".
-
jani@ua141d10.elisa.omakaista.fi authored
that in mysql_rm_table_part2_with_lock() previously we needed to open same file twice. Now once is enough.
-
konstantin@mysql.com authored
large table gives server crash": make sure that when a MyISAM temporary table is created for a cursor, it's created in its memory root, not the memory root of the current query.
-
igor@rurik.mysql.com authored
-
- 02 Nov, 2005 1 commit
-
-
igor@rurik.mysql.com authored
new file sql_table.cc, handler.h: Fixed bug #14540. Added error mnemonic code HA_ADMIN_NOT_BASE_TABLE to report that an operation cannot be applied for views. view.test, view.result: Added a test case for bug #14540. errmsg.txt: Fixed bug #14540. Added error ER_CHECK_NOT_BASE_TABLE.
-