An error occurred fetching the project authors.
- 28 Nov, 2006 1 commit
-
-
dli@dev3-76.dev.cn.tlan authored
ndb - fiexed for bug#15021, binlog_index table become inconsistent if errors during purge of binlogs. improved the original patch, changed if/else to switch/case.
-
- 26 Nov, 2006 1 commit
-
-
monty@mysql.com/nosik.monty.fi authored
Added missing DBUG_RETURN statements (in mysqldump.c) Added missing enums Fixed a lot of wrong DBUG_PRINT() statements, some of which could cause crashes Removed usage of %lld and %p in printf strings as these are not portable or produces different results on different systems.
-
- 21 Nov, 2006 2 commits
-
-
monty@mysql.com/nosik.monty.fi authored
Moved .progress files into the log directory Moved 'cluster' database tables into the MySQL database, to not have 'cluster' beeing a reserved database name Fixed bug where mysqld got a core dump when trying to use a table created by MySQL 3.23 Fixed some compiler warnings Fixed small memory leak in libmysql Note that this doesn't changeset doesn't include the new mysqldump.c code required to run some tests. This will be added when I merge 5.0 to 5.1
-
mats@romeo.(none) authored
Removing DBUG_DUMP printouts for valgrind builds since they trigger warnings. Removing valgrind memory checks completely. Removing bzero() of record when opening table that was added earlier.
-
- 20 Nov, 2006 1 commit
-
-
monty@mysql.com/nosik.monty.fi authored
(Mostly in DBUG_PRINT() and unused arguments) Fixed bug in query cache when used with traceing (--with-debug) Fixed memory leak in mysqldump Removed warnings from mysqltest scripts (replaced -- with #)
-
- 17 Nov, 2006 1 commit
-
-
open_table_from_share did not initialize table->record members. that was interpreted as the error by valgrind. Fixed with bzero-ing the members if compilation with -DHAVE_purify.
-
- 01 Nov, 2006 2 commits
-
-
monty@mysql.com/nosik.monty.fi authored
Fixed some possible fatal wrong arguments to printf() style functions Initialized some not initialized variables Fixed bug in stored procedure and continue handlers (Fixes Bug#22150)
-
igor@rurik.mysql.com authored
This is a performance issue for queries with subqueries evaluation of which requires filesort. Allocation of memory for the sort buffer at each evaluation of a subquery may take a significant amount of time if the buffer is rather big. With the fix we allocate the buffer at the first evaluation of the subquery and reuse it at each subsequent evaluation.
-
- 19 Oct, 2006 1 commit
-
-
We miss some records sometimes using RANGE method if we have partial key segments. Example: Create table t1(a char(2), key(a(1))); insert into t1 values ('a'), ('xx'); select a from t1 where a > 'x'; We call index_read() passing 'x' key and HA_READ_AFTER_KEY flag in the handler::read_range_first() wich is wrong because we have a partial key segment for the field and might miss records like 'xx'. Fix: don't use open segments in such a case.
-
- 16 Oct, 2006 1 commit
-
-
jani@ua141d10.elisa.omakaista.fi authored
-
- 13 Oct, 2006 2 commits
-
-
petr/cps@mysql.com/owlet.local authored
Bug #21785 "Server crashes after rename of the log table" and Bug #21966 "Strange warnings on create like/repair of the log tables" According to the patch, from now on, one should use RENAME to perform a log table rotation (this should also be reflected in the manual). Here is a sample: use mysql; CREATE TABLE IF NOT EXISTS general_log2 LIKE general_log; RENAME TABLE general_log TO general_log_backup, general_log2 TO general_log; The rules for Rename of the log tables are following: IF 1. Log tables are enabled AND 2. Rename operates on the log table and nothing is being renamed to the log table. DO 3. Throw an error message. ELSE 4. Perform rename. The very RENAME query will go the the old (backup) table. This is consistent with the behavoiur we have with binlog ROTATE LOGS statement. Other problems, which are solved by the patch are: 1) Now REPAIR of the log table is exclusive operation (as it should be), this also eliminates lock-related warnings. and 2) CREATE LIKE TABLE now usese usual read lock on the source table rather then name lock, which is too restrictive. This way we get rid of another log table-related warning, which occured because of the above fact (as a side-effect, name lock resulted in a warning).
-
dli@dev3-76.dev.cn.tlan authored
ndb - fixed for BUG#15021, binlog_index table become inconsistent if errors during purge of binlogs. if EMFILE error occured while purging binary logs, stop purging logs and report error message to user.
-
- 29 Sep, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
We use the condition from CHECK OPTION twice handling UPDATE command. First we construnct 'update_cond' AND 'option_cond' condition to select records to be updated, then we check the 'option_cond' for the updated row. The problem is that first 'AND' condition is optimized during the 'select' which can break 'option_cond' structure, so it will be unusable for the sectond use - to check the updated row. Possible soultion is either use copy of the condition in the first use or to make optimization less traumatic for the operands. I picked the first one.
-
- 28 Sep, 2006 1 commit
-
-
gluh@mysql.com/gluh.(none) authored
-
- 27 Sep, 2006 1 commit
-
-
gluh@mysql.com/gluh.(none) authored
-
- 19 Sep, 2006 1 commit
-
-
svoj@mysql.com/april.(none) authored
Fixed confusing error message from the storage engine when it fails to open underlying table. The error message is issued when a table is _opened_ (not when it is created).
-
- 15 Sep, 2006 1 commit
-
-
brian@zim.(none) authored
In practice this means that handlerton is now created by the server and is passed to the engine. Plugin startups can now also control how plugins are inited (and can optionally pass values). Bit more flexibility to those who want to write plugin interfaces to the database.
-
- 11 Sep, 2006 1 commit
-
-
gluh@mysql.com/gluh.(none) authored
0xFF is internal separator for SET|ENUM names. If this symbol is present in SET|ENUM names then we replace it with ','(deprecated symbol for SET|ENUM names) during frm creation and restore to 0xFF during frm opening
-
- 31 Aug, 2006 1 commit
-
-
mikael/pappa@dator5.(none) authored
Review fixes
-
- 30 Aug, 2006 1 commit
-
-
gluh@mysql.com/gluh.(none) authored
Bug#21432 Database/Table name limited to 64 bytes, not chars, problems with multi-byte
-
- 22 Aug, 2006 1 commit
-
-
mikael/pappa@dator5.(none) authored
BUG#21658: Crash when creating table with item in prepared statement that allocates memory in fix_fields We need to use an arena to indicate we are preparing a statement when loading partition function and parsing it as part of an open table.
-
- 21 Aug, 2006 1 commit
-
-
dlenev@mockturtle.local authored
from cache" and #21216 "Simultaneous DROP TABLE and SHOW OPEN TABLES causes server to crash". Crash happened when one ran DROP DATABASE or SHOW OPEN TABLES statements while concurrently doing DROP TABLE (or RENAME TABLE, CREATE TABLE LIKE or any other command that takes name-lock) in other connection. This problem was caused by the fact that table placeholders which were added to table cache in order to obtain name-lock on table had TABLE_SHARE::db and table_name set to 0. Therefore they broke assumption that these members are non-0 for all tables in table cache on which some of our code relies. The fix sets these members for such placeholders to appropriate value making this assumption true again. As attempt to avoid such problems in future we introduce auxiliary TABLE_SHARE::set_table_cache_key() methods which should be used when one wants to set TABLE_SHARE::table_cache_key and which ensure that TABLE_SHARE::table_name/db are set properly. Test cases for these bugs were added to 5.0 test-suite (with 5.0-specific fix for bug #21216).
-
- 17 Aug, 2006 1 commit
-
-
andrey@example.com authored
Post-review fixes. Mostly whitespace, int-to-bool return value, fixed comments
-
- 16 Aug, 2006 1 commit
-
-
gluh@mysql.com/gluh.(none) authored
return error if engine is disabled
-
- 09 Aug, 2006 1 commit
-
-
evgen@moonbone.local authored
After merge fix
-
- 08 Aug, 2006 1 commit
-
-
evgen@sunlight.local authored
Correct memory leak fix
-
- 02 Aug, 2006 1 commit
-
-
ingo/istruewing@chilla.local authored
Continued implementation of WL#1324 (table name to filename encoding) The intermediate (not temporary) files of the new table during ALTER TABLE was visible for SHOW TABLES. These intermediate files are copies of the original table with the changes done by ALTER TABLE. After all the data is copied over from the original table, these files are renamed to the original tables file names. So they are not temporary files. They persist after ALTER TABLE, but just with another name. In 5.0 the intermediate files are invisible for SHOW TABLES because all file names beginning with "#sql" were suppressed. This failed since 5.1.6 because even temporary table names were converted when making file names from them. The prefix became converted to "@0023sql". Converting the prefix during SHOW TABLES would suppress the listing of user tables that start with "#sql". The solution of the problem is to continue the implementation of the table name to file name conversion feature. One requirement is to suppress the conversion for temporary table names. This change is straightforward for real temporary tables as there is a function that creates temporary file names. But the generated path names are located in TMPDIR and have no relation to the internal table name. This cannot be used for ALTER TABLE. Its intermediate files need to be in the same directory as the old table files. And it is necessary to be able to deduce the same path from the same table name repeatedly. Consequently the intermediate table files must be handled like normal tables. Their internal names shall start with tmp_file_prefix (#sql) and they shall not be converted like normal table names. I added a flags parameter to all relevant functions that are called from ALTER TABLE. It is used to suppress the conversion for the intermediate table files. The outcome is that the suppression of #sql in SHOW TABLES works again. It does not suppress user tables as these are converted to @0023sql on file level. This patch does also fix ALTER TABLE ... RENAME, which could not rename a table with non-ASCII characters in its name. It does also fix the problem that a user could create a table like `#sql-xxxx-yyyy`, where xxxx is mysqld's pid and yyyy is the thread ID of some other thread, which prevented this thread from running ALTER TABLE. Some of the above problems are mentioned in Bug 1405, which can be closed with this patch. This patch does also contain some minor fixes for other forgotten conversions. Still known problems are reported as bugs 21370, 21373, and 21387.
-
- 14 Jul, 2006 1 commit
-
-
- 11 Jul, 2006 1 commit
-
-
kostja@bodhi.local authored
when dropping/creating tables"
-
- 06 Jul, 2006 3 commits
-
-
konstantin@bodhi.netgear authored
dropping/creating tables". The bug could lead to a crash when multi-delete statements were prepared and used with temporary tables. The bug was caused by lack of clean-up of multi-delete tables before re-execution of a prepared statement. In a statement like DELETE t1 FROM t1, t2 WHERE ... the first table list (t1) is moved to lex->auxilliary_table_list and excluded from lex->query_tables or select_lex->tables. Thus it was unaccessible to reinit_stmt_before_use and not cleaned up before re-execution of a prepared statement.
-
ingo@chilla.local authored
-
dlenev@mysql.com authored
before update trigger on NDB table". Two main changes: - We use TABLE::read_set/write_set bitmaps for marking fields used by statement instead of Field::query_id in 5.1. - Now when we mark columns used by statement we take into account columns used by table's triggers instead of marking all columns as used if table has triggers.
-
- 30 Jun, 2006 3 commits
-
-
evgen@moonbone.local authored
-
joerg@mysql.com authored
1.2525 06/06/30 18:29:27 monty@mysql.com +3 -0 Reverted wrong bug fix (Bug#11228)
-
monty@mysql.com authored
-
- 29 Jun, 2006 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
Table comment: issue a warning(error in traditional mode) if length of comment > 60 symbols Column comment: issue a warning(error in traditional mode) if length of comment > 255 symbols Table 'comment' is changed from char* to LEX_STRING
-
- 26 Jun, 2006 1 commit
-
-
ingo@mysql.com authored
Bug#17294 - INSERT DELAYED puting an \n before data Bug#16611 - INSERT DELAYED corrupts data Bug#13707 - Server crash with INSERT DELAYED on MyISAM table Combined as Bug#16218. INSERT DELAYED crashed in 5.0 on a table with a varchar that could be NULL and was created pre-5.0 (Bugs 16218 and 13707). INSERT DELAYED corrupted data in 5.0 on a table with varchar fields that was created pre-5.0 (Bugs 17294 and 16611). In case of INSERT DELAYED the open table is copied from the delayed insert thread to be able to create a record for the queue. When copying the fields, a method was used that did convert old varchar to new varchar fields and did not set up some pointers into the record buffer of the table. The field conversion was guilty for the misinterpretation of the record contents by the delayed insert thread. The wrong pointer setup was guilty for the crashes. For Bug 13707 (Server crash with INSERT DELAYED on MyISAM table) I fixed the above mentioned method to set up one of the pointers. For Bug 16218 I set up the other pointers too. But when looking at the corruptions I got aware that converting the field type was totally wrong for INSERT DELAYED. The copied table is used to create a record that is to be sent to the delayed insert thread. Of course it can interpret the record correctly only if all field types are the same in both table objects. So I revoked the fix for Bug 13707 and changed the new_field() method so that it can suppress conversions. No test case as this is a migration problem. One needs to create a table with 4.x and use it with 5.x. I added two test scripts to the bug report.
-
- 25 Jun, 2006 1 commit
-
-
evgen@sunlight.local authored
After merge fix
-
- 23 Jun, 2006 2 commits
-
-
iggy@mysql.com authored
-
bar@mysql.com authored
An UNIQUE KEY consisting of NOT NULL columns was displayed as PRIMARY KEY in "DESC t1". According to the code, that was intentional behaviour for some reasons unknown to me. This code was written before bitkeeper time, so I cannot check who and why made this. After discussing on dev-public, a decision was made to remove this code
-