- 08 Feb, 2008 2 commits
-
-
kostja@dipika.(none) authored
into dipika.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@dipika.(none) authored
table.
-
- 07 Feb, 2008 10 commits
-
-
davi@mysql.com/endora.local authored
On crashes generate a user-friendly resolved and demangled stack trace when libc provides the necessary functions (newer libc on i386, x86_64, powerpc, ia64, alpha and s390). Otherwise print a numeric stack trace as before, relying on resolve_stack_dump utility.
-
kostja@dipika.(none) authored
into dipika.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@dipika.(none) authored
-
malff@lambda.hsd1.co.comcast.net. authored
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-runtime
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-runtime
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-runtime
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.0-runtime
-
davi@mysql.com/endora.local authored
The problem is that one can not create a stored routine if sql_mode contains NO_ENGINE_SUBSTITUTION or PAD_CHAR_TO_FULL_LENGTH. Also when a event is created, the mode is silently lost if sql_mode contains one of the aforementioned. This was happening because the table definitions which stored sql_mode values weren't being updated to accept new values of sql_mode. The solution is to update, in a backwards compatible manner, the various table definitions (columns) that store the sql_mode value to take into account the new possible values. One incompatible change is that if a event that is being created can't be stored to the mysql.event table, an error will be raised. The tests case also ensure that new SQL modes will be added to the mysql.proc and mysql.event tables, otherwise the tests will fail.
-
- 06 Feb, 2008 5 commits
-
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
davi@mysql.com/endora.local authored
Changed "SHOW ENGINE ... STATUS" and "SHOW ENGINE ... MUTEX" to require the PROCESS privilege, instead of SUPER. Fixed by Damien Katz
-
anozdrin/alik@quad. authored
transfered by CREATE TABLE/SELECT to the new table.
-
davi@mysql.com/endora.local authored
Re-enable the test case for Bug 30331.
-
- 05 Feb, 2008 2 commits
-
-
anozdrin/alik@quad. authored
Bug 34311: main.lock_multi.test fails.
-
anozdrin/alik@quad. authored
-
- 04 Feb, 2008 2 commits
-
-
thek@adventure.(none) authored
Fixed interference between tests: Users were added but not properly removed. This caused later tests to fail.
-
davi@mysql.com/endora.local authored
The problem is that deprecated syntax warnings were not being suppressed when the stored routine is being parsed for the first execution. It's doesn't make sense to print out deprecated syntax warnings when the routine is being executed because this kind of warning only matters when the routine is being created. The solution is to suppress deprecated syntax warnings when parsing the stored routine for loading into the cache (might mean that the routine is being executed for the first time).
-
- 01 Feb, 2008 8 commits
-
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime
-
anozdrin/alik@quad. authored
-
thek@adventure.(none) authored
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/bug33201/my51-bug33201
-
thek@adventure.(none) authored
When issuing a column level grant on a table which require pre-locking the server crashed. The reason behind the crash was that data structures used by the lock api wasn't properly reinitialized in the case of a column level grant.
-
anozdrin/alik@quad. authored
into quad.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged
-
anozdrin/alik@quad. authored
-
anozdrin/alik@quad. authored
into quad.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged
-
- 30 Jan, 2008 2 commits
-
-
kostja@dipika.(none) authored
-
kostja@dipika.(none) authored
pre-locking. The crash was caused by an implicit assumption in check_table_access() that table_list parameter is always a part of lex->query_tables. When iterating over the passed list of tables, check_table_access() used to stop only when lex->query_tables_last_not_own was reached. In case of pre-locking, lex->query_tables_last_own is not NULL and points to some element of lex->query_tables. When the parameter of check_table_access() was not part of lex->query_tables, loop invariant could never be violated and a crash would happen when the current table pointer would point beyond the end of the provided list. The fix is to change the signature of check_table_access() to also accept a numeric limit of loop iterations, similarly to check_grant(), and supply this limit in all places when we want to check access of tables that are outside lex->query_tables, or just want to check access to one table.
-
- 29 Jan, 2008 3 commits
-
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
davi@mysql.com/endora.local authored
-
kostja@dipika.(none) authored
-
- 28 Jan, 2008 2 commits
-
-
davi@mysql.com/endora.local authored
-
davi@mysql.com/endora.local authored
The problem is that the Table_locks_waited was incremented only when the lock request succeed. If a thread waiting for the lock gets killed or the lock request is aborted, the variable would not be incremented, leading to inaccurate values in the variable. The solution is to increment the Table_locks_waited whenever the lock request is queued. This reflects better the intended behavior of the variable -- show how many times a lock was waited.
-
- 27 Jan, 2008 2 commits
-
-
tsmith@ramayana.hindu.god authored
into ramayana.hindu.god:/home/tsmith/m/bk/maint/51
-
tsmith@ramayana.hindu.god authored
and so that it works correctly on Windows.
-
- 25 Jan, 2008 2 commits
-
-
tsmith@ramayana.hindu.god authored
into ramayana.hindu.god:/home/tsmith/m/bk/maint/51
-
tsmith@ramayana.hindu.god authored
-