- 04 Oct, 2010 1 commit
-
-
Vasil Dimov authored
-
- 02 Oct, 2010 2 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
- 01 Oct, 2010 24 commits
-
-
Alexey Kopytov authored
conflicts: conflict dbug/dbug.c conflict sql/sql_load.cc
-
Alexey Kopytov authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Vasil Dimov authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Vasil Dimov authored
This is a null merge because it only contains InnoDB changes that originated in mysql-5.1-innodb and have been manually ported into mysql-5.5-innodb.
-
Vasil Dimov authored
-
Mattias Jonsson authored
-
Vasil Dimov authored
This is a manual merge from mysql-5.1-innodb of: revision-id: vasil.dimov@oracle.com-20100930102618-s9f9ytbytr3eqw9h committer: Vasil Dimov <vasil.dimov@oracle.com> timestamp: Thu 2010-09-30 13:26:18 +0300 message: Fix a potential bug when using __sync_lock_test_and_set() TYPE __sync_lock_test_and_set (TYPE *ptr, TYPE value, ...) it is not documented what happens if the two arguments are of different type like it was before: the first one was lock_word_t (byte) and the second one was 1 or 0 (int). Approved by: Marko (via IRC)
-
Mattias Jonsson authored
-
Mattias Jonsson authored
LOAD DATA into partitioned MyISAM table Problem was that both partitioning and myisam used the same table_share->mutex for different protections (auto inc and repair). Solved by adding a specific mutex for the partitioning auto_increment. Also adding destroying the ha_data structure in free_table_share (which is to be propagated into 5.5). This is a 5.1 ONLY patch, already fixed in 5.5+.
-
Mattias Jonsson authored
REBUILD PARTITION under LOCK TABLE Collapsed patch including updates from the reviews. In case of failure in ALTER ... PARTITION under LOCK TABLE the server could crash, due to it had modified the locked table object, which was not reverted in case of failure, resulting in a bad table definition used after the failed command. Solved by instead of altering the locked table object and its partition_info struct, creating an internal temporary intermediate table object used for altering, just like the non partitioned mysql_alter_table. So if an error occur before the alter operation is complete, the original table is not modified at all. But if the alter operation have succeeded so far that it must be completed as whole, the table is properly closed and reopened. (The completion on failure is done by the ddl_log.) mysql-test/suite/parts/inc/partition_fail.inc: Added tests under LOCK TABLE mysql-test/suite/parts/r/partition_debug_innodb.result: Updated results mysql-test/suite/parts/r/partition_debug_myisam.result: Updated results mysql-test/suite/parts/r/partition_special_innodb.result: updated result mysql-test/suite/parts/t/partition_special_innodb.test: changing comment, since this patch also fixes this. sql/sql_partition.cc: Added TODO, to use DBUG_SUICIDE() instead of abort() to avoid core-files on expected crashes. Removed unused arguments to fast_end_partition. Opening a intermediate table in prep_alter_part_table, instead of altering (a possible locked) normally opened table. That way we do not have to do anything more than close the intermediate table on error, leaving the ordinary table opened and locked. Also making sure that the intermediate table are closed/destroyed on failure. If no error occur it is later destroyed in the end of fast_alter_partition_table. Added ha_external_lock to make sure MyISAM flushed the index file after copying the partitions. This also leads to removal of the special close and removal from the table cache for other instances of the table. sql/sql_partition.h: Changed the arguments for prep_alter_part_table and fast_alter_partition_table to use an intermediate table instead of altering a (possibly locked) normal table. sql/sql_table.cc: Using an intermediate table created in prep_alter_part_table to be used in fast_alter_partition_table, also closing/destroying it on failure.
-
Jon Olav Hauglid authored
-
Bernt M. Johnsen authored
-
Vasil Dimov authored
This is a manual merge from mysql-5.1-innodb of: revno: 3618 revision-id: vasil.dimov@oracle.com-20100930124844-yglojy7c3vaji6dx parent: vasil.dimov@oracle.com-20100930102618-s9f9ytbytr3eqw9h committer: Vasil Dimov <vasil.dimov@oracle.com> branch nick: mysql-5.1-innodb timestamp: Thu 2010-09-30 15:48:44 +0300 message: Fix Bug#56340 innodb updates index stats too frequently after non-index updates This is a simple optimization issue. All stats are related to only indexed columns, index size or number of rows in the whole table. UPDATEs that touch only non-indexed columns cannot affect stats and we can avoid calling the function row_update_statistics_if_needed() which may result in unnecessary I/O. Approved by: Marko (rb://466) In addition to the above message: we know that row_update_cascade_for_mysql() (the other place where row_update_statistics_if_needed is called) always updates indexed columns (FK-related), so there is no need to add this cond there.
-
- 30 Sep, 2010 7 commits
-
-
Mattias Jonsson authored
Bug#57113: ha_partition::extra(ha_extra_function): Assertion `m_extra_cache' failed Fix for bug#55458 included DBUG_ASSERTS causing debug builds of the server to crash on another multi-table update. Removed the asserts since they where wrong. (updated after testing the patch in 5.5). mysql-test/r/partition.result: updated result mysql-test/t/partition.test: Added test for bug#57113 sql/ha_partition.cc: Removed the assert for m_extra_cache when ::extra(HA_PREPARE_FOR_UPDATE) was called.
-
Bernt M. Johnsen authored
inline perl in the test.
-
Dmitry Lenev authored
in the MDL deadlock detector". It is no longer needed as a better fix for this bug has been pushed.
-
Vasil Dimov authored
This is a simple optimization issue. All stats are related to only indexed columns, index size or number of rows in the whole table. UPDATEs that touch only non-indexed columns cannot affect stats and we can avoid calling the function row_update_statistics_if_needed() which may result in unnecessary I/O. Approved by: Marko (rb://466)
-
Georgi Kodinov authored
-
Jon Olav Hauglid authored
-
Vasil Dimov authored
TYPE __sync_lock_test_and_set (TYPE *ptr, TYPE value, ...) it is not documented what happens if the two arguments are of different type like it was before: the first one was lock_word_t (byte) and the second one was 1 or 0 (int). Approved by: Marko (via IRC)
-
- 29 Sep, 2010 5 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Dmitry Lenev authored
detector" that doesn't introduce bug #56715 "Concurrent transactions + FLUSH result in sporadical unwarranted deadlock errors". Deadlock could have occurred when workload containing a mix of DML, DDL and FLUSH TABLES statements affecting the same set of tables was executed in a heavily concurrent environment. This deadlock occurred when several connections tried to perform deadlock detection in the metadata locking subsystem. The first connection started traversing wait-for graph, encountered a sub-graph representing a wait for flush, acquired LOCK_open and dived into sub-graph inspection. Then it encountered sub-graph corresponding to wait for metadata lock and blocked while trying to acquire a rd-lock on MDL_lock::m_rwlock, since some,other thread had a wr-lock on it. When this wr-lock was released it could have happened (if there was another pending wr-lock against this rwlock) that the rd-lock from the first connection was left unsatisfied but at the same time the new rd-lock request from the second connection sneaked in and was satisfied (for this to be possible the second rd-request should come exactly after the wr-lock is released but before pending the wr-lock manages to grab rwlock, which is possible both on Linux and in our own rwlock implementation). If this second connection continued traversing the wait-for graph and encountered a sub-graph representing a wait for flush it tried to acquire LOCK_open and thus the deadlock was created. The previous patch tried to workaround this problem by not allowing the deadlock detector to lock LOCK_open mutex if some other thread doing deadlock detection already owns it and current search depth is greater than 0. Instead deadlock was reported. As a result it has introduced bug #56715. This patch solves this problem in a different way. It introduces a new rw_pr_lock_t implementation to be used by MDL subsystem instead of one based on Linux rwlocks or our own rwlock implementation. This new implementation never allows situation in which an rwlock is rd-locked and there is a blocked pending rd-lock. Thus the situation which has caused this bug becomes impossible with this implementation. Due to fact that this implementation is optimized for wr-lock/unlock scenario which is most common in the MDL subsystem it doesn't introduce noticeable performance regressions in sysbench tests. Moreover it significantly improves situation for POINT_SELECT test when many connections are used. No test case is provided as this bug is very hard to repeat in MTR environment but is repeatable with the help of RQG tests. This patch also doesn't include a test for bug #56715 "Concurrent transactions + FLUSH result in sporadical unwarranted deadlock errors" as it takes too much time to be run as part of normal test-suite runs. config.h.cmake: We no longer need to check for presence of pthread_rwlockattr_setkind_np as we no longer use Linux-specific implementation of rw_pr_lock_t which uses this function. configure.cmake: We no longer need to check for presence of pthread_rwlockattr_setkind_np as we no longer use Linux-specific implementation of rw_pr_lock_t which uses this function. configure.in: We no longer need to check for presence of pthread_rwlockattr_setkind_np as we no longer use Linux-specific implementation of rw_pr_lock_t which uses this function. include/my_pthread.h: Introduced new implementation of rw_pr_lock_t. Since it never allows situation in which rwlock is rd-locked and there is a blocked pending rd-lock it is not affected by bug #56405 "Deadlock in the MDL deadlock detector". This implementation is also optimized for wr-lock/unlock scenario which is most common in MDL subsystem. So it doesn't introduce noticiable performance regressions in sysbench tests (compared to old Linux-specific implementation). Moreover it significantly improves situation for POINT_SELECT test when many connections are used. As part of this change removed try-lock part of API for this type of lock. It is not used in our code and it would be hard to implement correctly within constraints of new implementation. Finally, removed support of preferring readers from my_rw_lock_t implementation as the only user of this feature was old rw_pr_lock_t implementation. include/mysql/psi/mysql_thread.h: Removed try-lock part of prlock API. It is not used in our code and it would be hard to implement correctly within constraints of new prlock implementation. mysys/thr_rwlock.c: Introduced new implementation of rw_pr_lock_t. Since it never allows situation in which rwlock is rd-locked and there is a blocked pending rd-lock it is not affected by bug #56405 "Deadlock in the MDL deadlock detector". This implementation is also optimized for wr-lock/unlock scenario which is most common in MDL subsystem. So it doesn't introduce noticiable performance regressions in sysbench tests (compared to old Linux-specific implementation). Moreover it significantly improves situation for POINT_SELECT test when many connections are used. Also removed support of preferring readers from my_rw_lock_t implementation as the only user of this feature was old rw_pr_lock_t implementation.
-
Vladislav Vaintroub authored
with CMake 2.8.3 builtin macro
-
Jon Olav Hauglid authored
This patch moves the regression test from variables.test to variables_debug.test as the debug system variable is not available on release builds.
-
- 28 Sep, 2010 1 commit
-
-
Alexander Nozdrin authored
-