- 16 Jul, 2007 11 commits
-
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@bodhi.(none) authored
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@bodhi.(none) authored
selected prior: ensure the fix also works for information_schema tables.
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@bodhi.(none) authored
Do not try to acquire structure_guard_mutex for the second time when invalidating a table from send_result_to_client.
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@bodhi.(none) authored
asserts. The patch for Bug#21074 replaces acquisition of the global LOCK_open lock with exclusive locks on table names in such operations ad DROP TABLE and RENAME TABLE. Unfortunately, NDB internally assumes that LOCK_open is acquired and tries to release it. This dependency should be fixed by a separate (and significant in size) patch. For now we just satisfy it - after all, the original goal of the patch for Bug#21074 was to move query_cache_invalidate outside of the scope of LOCK_open, and we still can do that. This fixes some failing NDB tests in the runtime tree.
-
df@pippilotta.erinye.com authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1
-
-
- 15 Jul, 2007 2 commits
-
-
kostja@bodhi.(none) authored
Linux Debug build (possible deadlock)" The bug is not repeatable any more.
-
kostja@bodhi.(none) authored
results. When executing a CREATE EVENT statement with ON COMPLETION NOT PRESERVE clause (explicit or implicit) and completion date in the past, we do not create the event. Or, put it differently, we create it and then drop immediately. A warning is issued in this case, not an error -- we want to load successfully old database dumps, and such dumps may contain events that are no longer valid. Update the warning text to not imply an erroneous condition.
-
- 14 Jul, 2007 2 commits
-
-
kostja@bodhi.(none) authored
-
kostja@bodhi.(none) authored
-
- 13 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
we now have exclusive name lock on the table name in mysql_rm_table_part2, we still should keep LOCK_open - some storage engines are not ready for locking scope change and assume that LOCK_open is kept. Still, the binary logging and query cache invalidation calls moved out of LOCK_open scope. Fixes some of the broken 5.1-runtime tests (tests break on asserts).
-
- 12 Jul, 2007 8 commits
-
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.(none) authored
incomplete in 5.0 (and review fixes). When in 5.0.13 I introduced class Prepared_statement and methods ::prepare and ::execute, general logging was left out of this class. This was good for stored procedures, since in stored procedures we do not log sub-statements, but introduced a regression in case of SQL syntax for prepared statements, as previously we would log the actual statements to the log, and after the change we would log only COM_QUERY text. Restore the old behavior, but still suppress logging if inside a stored procedure. Based on a community contributed patch from Vladimir Shebordaev. No test case since we do not have a mechanism to test output of the general log.
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-26141-final
-
kostja@bodhi.(none) authored
causes full table lock on innodb table. Also fixes Bug#28502 Triggers that update another innodb table will block on X lock unnecessarily (duplciate). Code review fixes. Both bugs' synopses are misleading: InnoDB table is not X locked. The statements, however, cannot proceed concurrently, but this happens due to lock conflicts for tables used in triggers, not for the InnoDB table. If a user had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (e.g. two distinct MyISAM tables), then these two triggers would not be able to execute concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would not be able to run concurrently. The problem had other side-effects (see respective bug reports). This behavior was a consequence of a shortcoming of the pre-locking algorithm, which would not distinguish between different DML operations (e.g. INSERT and DELETE) and pre-lock all the tables that are used by any trigger defined on the subject table. The idea of the fix is to extend the pre-locking algorithm to keep track, for each table, what DML operation it is used for and not load triggers that are known to never be fired.
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime
-
thek@adventure.(none) authored
A race condition in the integration between MyISAM and the query cache code caused the query cache to fail to invalidate itself on concurrently inserted data. This patch fix this problem by using the existing handler interface which, upon each statement cache attempt, compare the size of the table as viewed from the cache writing thread and with any snap shot of the global table state. If the two sizes are different the global table size is unknown and the current statement can't be cached.
-
anozdrin/alik@ibm. authored
SHOW CREATE TABLE or SELECT FROM I_S. This is the last patch for this bug, which depends on the big CS patch and was pending. The problem was that SHOW CREATE statements returned original queries in the binary character set. That could cause the query to be unreadable. The fix is to use original character_set_client when sending the original query to the client. In order to preserve the query in mysqldump, 'binary' character set results should be set when issuing SHOW CREATE statement. If either source or destination character set is 'binary' , no conversion is performed. The idea is that since the source character set is no longer 'binary', we fix the destination character set to still produce valid dumps.
-
- 11 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
Fix the parser to make the database options not optional.
-
- 10 Jul, 2007 4 commits
-
-
ramil/ram@ramil.myoffice.izhnet.ru authored
into mysql.com:/home/ram/work/mysql-5.1-maint
-
Problem: we don't take into account the length of the data written to the temporary data file during update on a CSV table. Fix: properly calculate the data file length during update.
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-new-maint
-
tomas@whalegate.ndb.mysql.com authored
- correct result files
-
- 09 Jul, 2007 11 commits
-
-
tsmith@sita.local authored
Dont touch & chmod the err_log file if using syslog (mysqld_safe)
-
tsmith@sita.local authored
into sita.local:/Users/tsmith/m/bk/maint/51
-
tsmith@sita.local authored
into sita.local:/Users/tsmith/m/bk/maint/50
-
tsmith@sita.local authored
Fix a few typos in comments (from Paul DuBois)
-
tsmith@sita.local authored
into sita.local:/Users/tsmith/m/bk/maint/51
-
tsmith@sita.local authored
Backport from 5.1 a fix to make this test deterministic
-
tsmith@sita.local authored
into sita.local:/Users/tsmith/m/bk/maint/51
-
tsmith@sita.local authored
into sita.local:/Users/tsmith/m/bk/maint/51
-
tsmith@sita.local authored
into sita.local:/Users/tsmith/m/bk/maint/50
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-new-maint
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-new-maint
-