- 14 Oct, 2004 6 commits
-
-
bell@sanja.is.com.ua authored
into sanja.is.com.ua:/home/bell/mysql/bk/work-4.1
-
bar@mysql.com authored
Wrong handler.
-
bar@mysql.com authored
-
bar@mysql.com authored
Bug#6086 "ctype_utf8" test fails when MySQL does not include InnoDB support
-
bell@sanja.is.com.ua authored
into sanja.is.com.ua:/home/bell/mysql/bk/work-4.1
-
bar@mysql.com authored
-
- 13 Oct, 2004 10 commits
-
-
konstantin@mysql.com authored
-
konstantin@mysql.com authored
into mysql.com:/media/sda1/mysql/mysql-4.1-5985
-
konstantin@mysql.com authored
crashes server." The fix makes Item_func_rand prepared-statements aware plus it fixes the case when RAND is used in prepared statements and replication is on (as well as several similar issues). Until now we did not reset THD before every execution of a prepared statement, so if some execution had set thd->time_zone_used or thd->rand_used they would not be reset until next mysql_parse. Some of post-review fixes done.
-
bell@sanja.is.com.ua authored
into sanja.is.com.ua:/home/bell/mysql/bk/work-4.1
-
heikki@hundin.mysql.fi authored
Implement innobase_very_fast_shutdown and innobase_start_trx_and_assign_read_view(); these were requested by Guilhem
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-4.1
-
ingo@mysql.com authored
BUG#4335 - one name can be handler open'ed many times. Fixed problems detected on Windows build by VC++. Removed unused variables. Applied a neccessary cast.
-
konstantin@mysql.com authored
Make checks (asserts) performed in client_test.c work in non-debug builds.
-
marko@hundin.mysql.fi authored
-
tomas@poseidon.ndb.mysql.com authored
-
- 12 Oct, 2004 6 commits
-
-
konstantin@mysql.com authored
(bad merge from 4.0)
-
mwagner@here.mwagner.org authored
Added catch for (example) WL#1234 into bk commit subjects
-
konstantin@mysql.com authored
propogation works only once (prepared statements)".
-
joerg@mysql.com authored
- 'ps_10nestset' uses a "nested set" approach for an employee hierarchy, then does arithmetic on the "salary" field; (soon) to be extended by inserts / deletes which imply mass updates on the "l"/"r" fields showing the set inclusion, - 'ps_11bugs' will get (some of ?) those bug DB entries which refer to prepared statements, but whose number does not appear in a test file comment - so it will also be extended.
-
konstantin@mysql.com authored
A fix for Bug#6042 "constants propogation works olny once (prepared statements)": reset item->marker in Item::cleanup, as it's used in propogate_cond_constants. No test case as the only way I could come up with to show the problem is EXPLAIN, and EXPLAIN is painful to use in the test suite.
-
pekka@mysql.com authored
-
- 11 Oct, 2004 5 commits
-
-
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1
-
tomas@poseidon.ndb.mysql.com authored
-
into a193-229-222-105.elisa-laajakaista.fi:/home/my/bk/mysql-4.1
-
section, which had gotten somewhat out-dated.
-
- 10 Oct, 2004 8 commits
-
-
ram@gw.mysql.r18.ru authored
into gw.mysql.r18.ru:/usr/home/ram/work/4.1.b5382
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1
-
ram@gw.mysql.r18.ru authored
-
ram@gw.mysql.r18.ru authored
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1
-
tomas@poseidon.ndb.mysql.com authored
Fixes bug with tableImpl with blobs not being initialized properly w.r.t pointer to blob tableImpl in column added blob to test to see that blob tables don't show up in show tables auto increment setting need not fetch blob tables (will otherwise generate error during table creation) moved addBlobTables out of fetchGlobalTableImpl to get_local_table_info changed addBlobTables to start from last column and break if all blobs added also addBlobTables will return -1 if failed (typically getTable) changed to using get_local_table_info with internal table name where applicable for efficiency added option to get_local_table_info wether to fetch blob tables or not getTable always fetches the blobtables moved addBlobTables to get_local_table_info to always be called, even if main table goes to cache only
-
ram@gw.mysql.r18.ru authored
into gw.mysql.r18.ru:/usr/home/ram/work/4.1.gconcat
-
ram@gw.mysql.r18.ru authored
(Bug #4315: GROUP_CONCAT with ORDER BY returns strange results for TEXT fields Bug #5564: Strange behaviour with group_concat and distinct Bug #5970: group_concat doesn't print warnings)
-
- 09 Oct, 2004 5 commits
-
-
konstantin@mysql.com authored
change, and perform it (the new Item changes registry).
-
konstantin@mysql.com authored
into mysql.com:/media/sda1/mysql/mysql-4.1-hook
-
konstantin@mysql.com authored
crashes server (prepared statements)": the bug was that all boolean items always recovered its original arguments at statement cleanup stage. This collided with Item_subselect::select_transformer, which tries to permanently change the item tree to use a transformed subselect instead of original one. So we had this call sequence for prepare: mysql_stmt_prepare -> JOIN::prepare -> Item_subselect::fix_fields -> the item tree gets transformed -> Item_bool_rowready_func2::cleanup, item tree is recovered to original state, while it shouldn't have been; mysql_stmt_execute -> attempts to execute a broken tree -> crash. Now instead of bluntly recovering all arguments of bool functions in Item_bool_rowready_func2::cleanup, we recover only those which were changed, and do it in one place. There still would exist a possibility for a collision with subselect tranformation, if permanent and temporary changes were performed at the same stage. But fortunately subselect transformation is always done first, so it doesn't conflict with the optimization done by propogate_cond_constants. Now we have: mysql_stmt_prepare -> JOIN::prepare -> subselect transformation permanently changes the tree -> cleanup doesn't recover anything, because nothing was registered for recovery. mysql_stmt_execute -> JOIN::prepare (the tree is already transformed, so it doesn't change), JOIN::optimize -> propogate_cond_constants -> temporary changes the item tree with constants -> JOIN::execute -> cleanup -> the changes done by propogate_cond_constants are recovered, as they were registered for recovery.
-
mysqld_multi via mysqld_multi.server.sh
-
was given.
-