- 30 Aug, 2006 1 commit
-
-
kostja@bodhi.local authored
-
- 29 Aug, 2006 7 commits
-
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.1-runtime-merge
-
kostja@bodhi.local authored
doesn't find the column" When a user was using 4.1 tables with VARCHAR column and 5.0 server and a query that used a temporary table to resolve itself, the table metadata for the varchar column sent to client was incorrect: MYSQL_FIELD::table member was empty. The bug was caused by implicit "upgrade" from old VARCHAR to new VARCHAR hard-coded in Field::new_field, which did not preserve the information about the original table. Thus, the field metadata of the "upgraded" field pointed to an auxiliary temporary table created for query execution. The fix is to copy the pointer to the original table to the new field.
-
timour/timka@lamia.home authored
into lamia.home:/home/timka/mysql/src/5.1-bug-21456
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug17591
-
anozdrin/alik@alik. authored
- BUG#15934: Instance manager fails to work; - BUG#18020: IM connect problem; - BUG#18027: IM: Server_ID differs; - BUG#18033: IM: Server_ID not reported; - BUG#21331: Instance Manager: Connect problems in tests; The only test suite has been changed (server codebase has not been modified).
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug17591
-
kroki/tomash@moonlight.intranet authored
When a view was used inside a trigger or a function, lock type for tables used in a view was always set to READ (thus making the view non-updatable), even if we were trying to update the view. The solution is to set lock type properly.
-
- 25 Aug, 2006 9 commits
-
-
brian@zim.(none) authored
into zim.(none):/home/brian/mysql/arch-5.1
-
brian@zim.(none) authored
into zim.(none):/home/brian/mysql/arch-5.1
-
brian@zim.(none) authored
Fixed "discover" in the handler API. Fixed problem where handlerton was not zero'ed. I need to look around, I suspect this problem is more widespread.
-
andrey@example.com authored
into example.com:/work/mysql-5.0-runtime
-
andrey@example.com authored
erroneous check Problem: Actually there were two problems in the server code. The check for SQLCOM_FLUSH in SF/Triggers were not according to the existing architecture which uses sp_get_flags_for_command() from sp_head.cc . This function was also missing a check for SQLCOM_FLUSH which has a problem combined with prelocking. This changeset fixes both of these deficiencies as well as the erroneous check in sp_head::is_not_allowed_in_function() which was a copy&paste error.
-
anozdrin/alik@alik. authored
into alik.:/mnt/raid/alik/MySQL/devel/5.0-rt-bug16899
-
-
kroki/tomash@moonlight.intranet authored
-
-
- 24 Aug, 2006 5 commits
-
-
andrey@example.com authored
The following procedure was not possible if max_sp_recursion_depth is 0 create procedure show_proc() show create procedure show_proc; Actually there is no recursive call but the limit is checked. Solved by temporarily increasing the thread's limit just before the fetch from cache and decreasing after that.
-
anozdrin/alik@alik. authored
Changed trigger-handling code so that there will be the one place for generate statement string for replication log and for trigger file.
-
petr/cps@owlet.local authored
into mysql.com:/home/cps/mysql/trees/mysql-5.1-virgin
-
petr/cps@mysql.com/owlet.local authored
-
kroki/tomash@moonlight.intranet authored
Changes in an item tree done by optimizer weren't properly registered and went unnoticed, which resulted in preliminary freeing of used memory.
-
- 23 Aug, 2006 10 commits
-
-
brian@zim.(none) authored
-
brian@zim.(none) authored
-
anozdrin/alik@alik. authored
User name (host name) has limit on length. The server code relies on these limits when storing the names. The problem was that sometimes these limits were not checked properly, so that could lead to buffer overflow. The fix is to check length of user/host name in parser and if string is too long, throw an error.
-
timour/timka@lamia.home authored
into lamia.home:/home/timka/mysql/src/5.0-bug-21456
-
andrey@example.com authored
into example.com:/work/mysql-5.1-runtime
-
andrey@example.com authored
should work in Prepared Statements. Post-review changeset. Problem: There are some commands which are avaiable to be executed in SP but cannot be prepared. This patch fixes this and makes it possible prepare these statements. Changes: The commands later are made available in PS. RESET has been forbidden in SF/Trigger. Solution: All current server commands where checked and those missing (see later) we added. Tests for all of the commands with repeated executions were added - testing with SP, SF and PS. SHOW BINLOG EVENTS SHOW (MASTER | SLAVE) STATUS SHOW (MASTER | BINARY) LOGS SHOW (PROCEDURE | FUNCTION) CODE (parsable only in debug builds) SHOW CREATE (PROCEDURE | FUNCTION | EVENT | TABLE | VIEW) SHOW (AUTHORS | CONTRIBUTORS | WARNINGS | ERRORS) CHANGE MASTER RESET (MASTER | SLAVE | QUERY CACHE) SLAVE (START | STOP) CHECKSUM (TABLE | TABLES) INSTALL PLUGIN UNINSTALL PLUGIN CACHE INDEX LOAD INDEX INTO CACHE GRANT REVOKE KILL (CREATE | RENAME | DROP) DATABASE (CREATE | RENAME | DROP) USER FLUSH (TABLE | TABLES | TABLES WITH READ LOCK | HOSTS | PRIVILEGES | LOGS | STATUS | MASTER | SLAVE | DES_KEY_FILE | USER_RESOURCES)
-
timour/timka@lamia.home authored
GROUP BY/DISTINCT pruning optimization must be done before ORDER BY optimization because ORDER BY may be removed when GROUP BY/DISTINCT sorts as a side effect, e.g. in SELECT DISTINCT <non-key-col>,<pk> FROM t1 ORDER BY <non-key-col> DISTINCT must be removed before ORDER BY as if done the other way around it will remove both.
-
petr/cps@owlet.local authored
into mysql.com:/home/cps/mysql/trees/mysql-5.1-virgin
-
petr/cps@owlet.local authored
into mysql.com:/home/cps/mysql/trees/mysql-5.1-virgin
-
malff/marcsql@weblab.(none) authored
Implemented code review comments Test cleanup
-
- 22 Aug, 2006 5 commits
-
-
brian@zim.(none) authored
Plugins now when compiled or not compiled work correctly with status variables. Status variables from plugins now set their own names (removed bit where plugin name was pre-appended this broke Innodb and Cluster) A few Makefile cleanups.
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.0-8153
-
msvensson@neptunus.(none) authored
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21051-2
-
kroki/tomash@moonlight.intranet authored
There were two problems: RESET QUERY CACHE took a long time to complete and other threads were blocked during this time. The patch does three things: 1 fixes a bug with improper use of test-lock-test_again technique. AKA Double-Checked Locking is applicable here only in few places. 2 Somewhat improves performance of RESET QUERY CACHE. Do my_hash_reset() instead of deleting elements one by one. Note however that the slowdown also happens when inserting into sorted list of free blocks, should be rewritten using balanced tree. 3 Makes RESET QUERY CACHE non-blocking. The patch adjusts the locking protocol of the query cache in the following way: it introduces a flag flush_in_progress, which is set when Query_cache::flush_cache() is in progress. This call sets the flag on enter, and then releases the lock. Every other call is able to acquire the lock, but does nothing if flush_in_progress is set (as if the query cache is disabled). The only exception is the concurrent calls to Query_cache::flush_cache(), that are blocked until the flush is over. When leaving Query_cache::flush_cache(), the lock is acquired and the flag is reset, and one thread waiting on Query_cache::flush_cache() (if any) is notified that it may proceed.
-
- 21 Aug, 2006 3 commits
-
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/merge/mysql-5.1
-
rburnett@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.1-kt
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/merge/mysql-5.1
-