- 27 Jun, 2006 9 commits
-
-
joerg@mysql.com authored
into mysql.com:/M50/autopush20216-5.0
-
joerg@mysql.com authored
-
joerg@mysql.com authored
This finishes bug#18516, as far as "generic RPMs" are concerned.
-
joerg@mysql.com authored
-
joerg@mysql.com authored
manual merge from 4.0.
-
joerg@mysql.com authored
-
konstantin@mysql.com authored
-
konstantin@mysql.com authored
-
konstantin@mysql.com authored
Fix a minor issue with Bug#16206 (bdb.test failed if the tree is compiled without blackhole).
-
- 26 Jun, 2006 14 commits
-
-
konstantin@mysql.com authored
into mysql.com:/opt/local/work/mysql-5.0-17199
-
kent@mysql.com authored
into mysql.com:/Users/kent/mysql/bk/mysql-5.0-new
-
kent@mysql.com authored
into mysql.com:/Users/kent/mysql/bk/mysql-5.0-new
-
kent@mysql.com authored
into mysql.com:/Users/kent/mysql/bk/mysql-4.1-new
-
kent@mysql.com authored
For compatibility, don't use {..,..} in pattern matching make_binary_distribution.sh: Added .dylib and .sl as shared library extensions
-
konstantin@mysql.com authored
into mysql.com:/opt/local/work/mysql-5.0-17199
-
konstantin@mysql.com authored
Bug#19022 "Memory bug when switching db during trigger execution" Bug#17199 "Problem when view calls function from another database." Bug#18444 "Fully qualified stored function names don't work correctly in SELECT statements" Documentation note: this patch introduces a change in behaviour of prepared statements. This patch adds a few new invariants with regard to how THD::db should be used. These invariants should be preserved in future: - one should never refer to THD::db by pointer and always make a deep copy (strmake, strdup) - one should never compare two databases by pointer, but use strncmp or my_strncasecmp - TABLE_LIST object table->db should be always initialized in the parser or by creator of the object. For prepared statements it means that if the current database is changed after a statement is prepared, the database that was current at prepare remains active. This also means that you can not prepare a statement that implicitly refers to the current database if the latter is not set. This is not documented, and therefore needs documentation. This is NOT a change in behavior for almost all SQL statements except: - ALTER TABLE t1 RENAME t2 - OPTIMIZE TABLE t1 - ANALYZE TABLE t1 - TRUNCATE TABLE t1 -- until this patch t1 or t2 could be evaluated at the first execution of prepared statement. CURRENT_DATABASE() still works OK and is evaluated at every execution of prepared statement. Note, that in stored routines this is not an issue as the default database is the database of the stored procedure and "use" statement is prohibited in stored routines. This patch makes obsolete the use of check_db_used (it was never used in the old code too) and all other places that check for table->db and assign it from THD::db if it's NULL, except the parser. How this patch was created: THD::{db,db_length} were replaced with a LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were manually checked and: - if the place uses thd->db by pointer, it was fixed to make a deep copy - if a place compared two db pointers, it was fixed to compare them by value (via strcmp/my_strcasecmp, whatever was approproate) Then this intermediate patch was used to write a smaller patch that does the same thing but without a rename. TODO in 5.1: - remove check_db_used - deploy THD::set_db in mysql_change_db See also comments to individual files.
-
ingo@mysql.com authored
into mysql.com:/nfstmp1/ingo/autopush-75/mysql-5.0
-
anozdrin@mysql.com authored
into mysql.com:/home/alik/MySQL/devel/5.0-rt
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug16986-main
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug16986-main
-
ingo@mysql.com authored
Addendum fixes after changing the condition variable for the global read lock. The stress test suite revealed some deadlocks. Some were related to the new condition variable (COND_global_read_lock) and some were general problems with the global read lock. It is now necessary to signal COND_global_read_lock whenever COND_refresh is signalled. We need to wait for the release of a global read lock if one is set before every operation that requires a write lock. But we must not wait if we have locked tables by LOCK TABLES. After setting a global read lock a thread waits until all write locks are released.
-
tnurnberg@mysql.com authored
into mysql.com:/home/tnurnberg/mysql-5.0-maint-18462
-
elliot@mysql.com authored
into mysql.com:/data0/bk/mysql-5.0-maint
-
- 24 Jun, 2006 2 commits
-
-
knielsen@mysql.com authored
into mysql.com:/data0/knielsen/tmp-5.0
-
knielsen@mysql.com authored
Sometimes the helper connection (that is watching for the main connection to time out) would itself time out first, causing the test to fail.
-
- 23 Jun, 2006 10 commits
-
-
iggy@mysql.com authored
into mysql.com:/mnt/storeage/mysql-5.0-maint_bug20616
-
iggy@mysql.com authored
-
evgen@moonbone.local authored
After merge fix
-
elliot@mysql.com authored
-
knielsen@mysql.com authored
into mysql.com:/usr/local/mysql/tmp-5.0
-
knielsen@mysql.com authored
The problem was a call to convert_dirname() with a destination buffer that did not have room for the trailing slash added by that function. This could cause the instance manager to crash in some cases.
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
joerg@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
-
- 22 Jun, 2006 5 commits
-
-
kent@mysql.com authored
Disable the simplistic auto dependency scan for test/bench (bug#20078)
-
tnurnberg@mysql.com authored
into mysql.com:/home/tnurnberg/mysql-5.0-maint-19409
-
konstantin@mysql.com authored
into mysql.com:/opt/local/work/mysql-5.0-runtime
-
pekka@clam.ndb.mysql.com authored
into clam.ndb.mysql.com:/space/pekka/ndb/version/my50-bug18781
-
tnurnberg@mysql.com authored
- The setting of "ENV{'TZ'}" doesn't affect the timezone used by MySQL Server on Windows. - Explicitly set timezone in test cases before doing UTC/localtime conversions so tests produce deterministic results
-