- 12 Aug, 2005 12 commits
-
-
osku@127.(none) authored
into 127.(none):/home/osku/mysql-5.0
-
bar@mysql.com authored
After merge change. 4.1 method was replaced in 5.0.
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-5.0
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-4.1.b12351
-
igor@rurik.mysql.com authored
A safety correction.
-
osku@127.(none) authored
into 127.(none):/home/osku/mysql-5.0
-
osku@127.(none) authored
most notably deadlocked ones in SHOW INNODB STATUS. Fixes bug #7819.
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/dev/mysql-5.0-0
-
igor@rurik.mysql.com authored
Fixed bug #12470. A misplaced initialization of the cond_count counter resulted in a wrong calculation of it. This caused a memory corruption since this counter was used as a parameter of some memory allocation. view.test: Added a test case for bug #12470.
-
jimw@mysql.com authored
number of seconds (which can include microseconds). (Bug #6760)
-
patg@radha.local authored
into radha.local:/Users/patg/mysql-build/mysql-4.1.clean
-
jimw@mysql.com authored
earlier change wasn't correct. (But the other changes to the test were.)
-
- 11 Aug, 2005 14 commits
-
-
igor@rurik.mysql.com authored
Fixed bug #12382. INSERT statement effectively changed thd->set_query_id to 0, while SELECT statement changed it to 0. As a result the insert_fields function that expanded '*' was called with different values of thd->set_query_id for the query SELECT * FROM view depending on whether it was run after an INSERT or after a SELECT statement. This was corrected by restoring the old value of thd->set_query_id when returning from the function setup_fields where possible reset could occur. If the value of thd->set_query_id == 0 then the fields substituted instead of '*' were not registered as used for bitmaps used_keys. This caused selection of an invalid execution plan for the query SELECT * from <view>. view.result, view.test: Added a test case for bug #12382.
-
jimw@mysql.com authored
into mysql.com:/home/jimw/my/mysql-5.0-clean
-
jimw@mysql.com authored
into mysql.com:/home/jimw/my/mysql-5.0-clean
-
jimw@mysql.com authored
automatically. (Bug #12324)
-
vtkachenko@quadxeon.mysql.com authored
into quadxeon.mysql.com:/users/vtkachenko/bk/mysql-5.0-tmp
-
acurtis@xiphis.org authored
into xiphis.org:/usr/home/antony/work2/merge-5.0
-
acurtis@xiphis.org authored
-
jani@ua141d10.elisa.omakaista.fi authored
sql_print_warning() and sql_print_error() instead of fprintf to stderr. Above functions are tuned for different platforms so that the behavior is consistent around platforms. Using fprintf() different behavior can be expected at least on Windows and Unix.
-
vtkachenko@quadxeon.mysql.com authored
Added innodb_commit_concurrency variable
-
acurtis@xiphis.org authored
into xiphis.org:/usr/home/antony/work2/merge-5.0
-
sanja@arthur.local authored
postmerge fix
-
bell@51.0.168.192.in-addr.arpa authored
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-5.0-bg11973-2
-
bell@51.0.168.192.in-addr.arpa authored
-
- 10 Aug, 2005 14 commits
-
-
patg@radha.local authored
in invoking mysqlcheck.
-
acurtis@xiphis.org authored
into xiphis.org:/usr/home/antony/work2/p2-bug10109.4
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.0-bug12228-r5
-
sergefp@mysql.com authored
-
jimw@mysql.com authored
-
bell@52.0.168.192.in-addr.arpa authored
-
konstantin@mysql.com authored
cursors (+ commit)" and Bug#11832 "Server crash with InnoDB + Cursors" See comments to the changed files.
-
konstantin@mysql.com authored
into mysql.com:/home/kostja/mysql/mysql-5.0-12243
-
konstantin@mysql.com authored
-
reggie@linux.site authored
into linux.site:/home/reggie/bk/mysql-5.0-new
-
hf@deer.(none) authored
-
mskold@mysql.com authored
into mysql.com:/usr/local/home/marty/MySQL/mysql-5.0
-
konstantin@mysql.com authored
subqry order by server crash": failing DBUG_ASSERT(curr_join == this) when opening a cursor. Ensure that for top-level join curr_join == join (always), and thus fix the failing assert. curr_join is a hack to ensure that uncacheable subqueries can be re-evaluated safely, and should be never different from main join in case of top-level join.
-
mskold@mysql.com authored
into mysql.com:/usr/local/home/marty/MySQL/mysql-4.1
-