- 31 Aug, 2006 8 commits
-
-
mikael/pappa@dator5.(none) authored
-
mikael/pappa@dator5.(none) authored
into dator5.(none):/home/pappa/push_clone
-
mikael/pappa@dator5.(none) authored
into dator5.(none):/home/pappa/push_clone
-
gluh@mysql.com/gluh.(none) authored
fixed error message
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.1-runtime-merge
-
mikael/pappa@dator5.(none) authored
into dator5.(none):/home/pappa/bug21388
-
mikael/pappa@dator5.(none) authored
into dator5.(none):/home/pappa/bug21388
-
mikael/pappa@dator5.(none) authored
Review fixes
-
- 30 Aug, 2006 5 commits
-
-
kostja@bodhi.local authored
-
rburnett@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.1-kt
-
Reggie@blackhole. authored
-
georg@lmy002.wdf.sap.corp authored
CMake versions > 2.4 allow linking to STATIC or SHARED libraries only.
-
gluh@mysql.com/gluh.(none) authored
skip engine handling if engine is disabled
-
- 29 Aug, 2006 8 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.
-
rburnett@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.1-kt
-
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.
-
- 28 Aug, 2006 1 commit
-
-
rburnett@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.1-kt
-
- 26 Aug, 2006 2 commits
-
-
mikael/pappa@dator5.(none) authored
-
mikael/pappa@dator5.(none) authored
into dator5.(none):/home/pappa/bug21388
-
- 25 Aug, 2006 10 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
-
-
rburnett@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.1-kt
-
- 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 1 commit
-
-
brian@zim.(none) authored
-