- 16 May, 2007 11 commits
-
-
unknown authored
into trift2.:/MySQL/M51/push-5.1
-
unknown authored
Ensure the balanced use of 'x' guards in string comparisons also in the new 5.1 lines. scripts/make_win_bin_dist: After-merge fix: Ensure the balanced use of 'x' guards in string comparisons also in the new 5.1 lines.
-
unknown authored
-
unknown authored
so that changes from 5.0 propagate (on merge) into the 5.1 version. BitKeeper/deleted/.del-make_win_bin_dist-HIDE: Delete: scripts/make_win_bin_dist-HIDE scripts/make_win_bin_dist: Transfer the current contents of the 5.1 version into this file. This is *no* contents change, its *only* purpose is to ensure that the 5.1 version of this file depends on the 5.0 version, and changes from 5.0 propagate properly into 5.1.
-
unknown authored
open bug report, reproduced in the runtime team tree). sql/event_data_objects.cc: Make a stub at fixing a race in event_bugs.test under valgrind: read of uninitialized byte in SHOW PROCESSLIST from an event thread.
-
unknown authored
into vajra.(none):/opt/local/work/mysql-5.1-21483 sql/sql_insert.cc: Auto merged
-
unknown authored
sql/sql_insert.cc: Do not access delayed thread memory without a mutex.
-
unknown authored
sql/sql_insert.cc: Correct a merge error (wrong declaration was used).
-
unknown authored
into vajra.(none):/opt/local/work/mysql-5.1-21483 sql/sp_head.cc: Auto merged sql/sql_base.cc: Auto merged sql/sql_lex.h: Auto merged mysql-test/r/insert.result: Manual merge. mysql-test/t/insert.test: Manual merge. sql/sql_insert.cc: Manual merge.
-
unknown authored
into vajra.(none):/opt/local/work/mysql-5.0-21483 sql/sp_head.cc: Auto merged sql/sql_base.cc: Auto merged sql/sql_insert.cc: Auto merged sql/sql_lex.h: Auto merged
-
unknown authored
Bug#21483 "Server abort or deadlock on INSERT DELAYED with another implicit insert" Also fixes and adds test cases for bugs: 20497 "Trigger with INSERT DELAYED causes Error 1165" 21714 "Wrong NEW.value and server abort on INSERT DELAYED to a table with a trigger". Post-review fixes. Problem: In MySQL INSERT DELAYED is a way to pipe all inserts into a given table through a dedicated thread. This is necessary for simplistic storage engines like MyISAM, which do not have internal concurrency control or threading and thus can not achieve efficient INSERT throughput without support from SQL layer. DELAYED INSERT works as follows: For every distinct table, which can accept DELAYED inserts and has pending data to insert, a dedicated thread is created to write data to disk. All user connection threads that attempt to delayed-insert into this table interact with the dedicated thread in producer/consumer fashion: all records to-be inserted are pushed into a queue of the dedicated thread, which fetches the records and writes them. In this design, client connection threads never open or lock the delayed insert table. This functionality was introduced in version 3.23 and does not take into account existence of triggers, views, or pre-locking. E.g. if INSERT DELAYED is called from a stored function, which, in turn, is called from another stored function that uses the delayed table, a deadlock can occur, because delayed locking by-passes pre-locking. Besides: * the delayed thread works directly with the subject table through the storage engine API and does not invoke triggers * even if it was patched to invoke triggers, if triggers, in turn, used other tables, the delayed thread would have to open and lock involved tables (use pre-locking). * even if it was patched to use pre-locking, without deadlock detection the delayed thread could easily lock out user connection threads in case when the same table is used both in a trigger and on the right side of the insert query: the delayed thread would not release locks until all inserts are complete, and user connection can not complete inserts without having locks on the tables used on the right side of the query. Solution: These considerations suggest two general alternatives for the future of INSERT DELAYED: * it is considered a full-fledged alternative to normal INSERT * it is regarded as an optimisation that is only relevant for simplistic engines. Since we missed our chance to provide complete support of new features when 5.0 was in development, the first alternative currently renders infeasible. However, even the second alternative, which is to detect new features and convert DELAYED insert into a normal insert, is not easy to implement. The catch-22 is that we don't know if the subject table has triggers or is a view before we open it, and we only open it in the delayed thread. We don't know if the query involves pre-locking until we have opened all tables, and we always first create the delayed thread, and only then open the remaining tables. This patch detects the problematic scenarios and converts DELAYED INSERT to a normal INSERT using the following approach: * if the statement is executed under pre-locking (e.g. from within a stored function or trigger) or the right side may require pre-locking, we detect the situation before creating a delayed insert thread and convert the statement to a conventional INSERT. * if the subject table is a view or has triggers, we shutdown the delayed thread and convert the statement to a conventional INSERT. mysql-test/r/insert.result: Update test results. mysql-test/t/insert.test: Add a test case for Bug#21483, Bug#20497, Bug#21714 (INSERT DELAYED and stored routines, triggers). sql/sp_head.cc: Upgrade lock type to TL_WRITE when computing the pre-locking set. sql/sql_base.cc: Use a new method. sql/sql_insert.cc: INSERT DELAYED and pre-locking: - if under pre-locking, upgrade the lock type to TL_WRITE and proceed as a normal write - if DELAYED table has triggers, also request a lock upgrade. - make sure errors in the delayed thread are propagated correctly sql/sql_lex.h: Add a method to check if a parsed tree refers to stored routines.
-
- 15 May, 2007 7 commits
-
-
unknown authored
Several string comparisons could never yield true because they had an 'x' guard added to the variable but not to the constant value. Fix that by guarding both sides. scripts/make_win_bin_dist: Fix bug#27833 "Bourne shell string comparison issue in scripts/make_win_bin_dist": Several string comparisons could never yield true because they had an 'x' guard added to the variable but not to the constant value. Fix that by guarding both sides. Use this occasion to apply some corrections to the comments and the usage text. Also, ensure the ".pdb" file is always optional.
-
unknown authored
into vajra.(none):/opt/local/work/mysql-5.1-runtime sql/item.cc: Auto merged sql/item_func.cc: Auto merged sql/mysql_priv.h: Auto merged sql/set_var.cc: Auto merged sql/sql_class.h: Auto merged sql/sql_insert.cc: Auto merged sql/sql_parse.cc: Auto merged sql/sql_prepare.cc: Auto merged sql/sql_yacc.yy: Auto merged mysql-test/t/disabled.def: Manual merge.
-
unknown authored
-
unknown authored
into vajra.(none):/opt/local/work/mysql-5.1-runtime mysql-test/include/mix1.inc: Auto merged mysql-test/r/innodb_mysql.result: Auto merged mysql-test/r/ps_1general.result: Auto merged mysql-test/t/disabled.def: Auto merged mysql-test/t/ps_1general.test: Auto merged sql/ha_ndbcluster.cc: Auto merged sql/ha_ndbcluster_binlog.cc: Auto merged sql/item.cc: Auto merged sql/item_func.cc: Auto merged sql/mysql_priv.h: Auto merged sql/set_var.cc: Auto merged sql/sql_base.cc: Auto merged sql/sql_cache.cc: Auto merged sql/sql_class.cc: Auto merged sql/sql_class.h: Auto merged sql/sql_lex.cc: Auto merged sql/sql_lex.h: Auto merged sql/sql_parse.cc: Auto merged sql/sql_partition.cc: Auto merged sql/sql_prepare.cc: Auto merged sql/sql_table.cc: Auto merged sql/sql_yacc.yy: Auto merged sql/table.h: Auto merged sql/sql_insert.cc: SCCS merged
-
unknown authored
into vajra.(none):/opt/local/work/mysql-5.0-runtime
-
unknown authored
into vajra.(none):/opt/local/work/mysql-5.0-runtime sql/item.cc: Auto merged sql/item_func.cc: Auto merged sql/mysql_priv.h: Auto merged sql/set_var.cc: Auto merged sql/sql_class.h: Auto merged sql/sql_insert.cc: Auto merged sql/sql_parse.cc: Auto merged sql/sql_prepare.cc: Auto merged sql/sql_yacc.yy: Auto merged
-
unknown authored
into vajra.(none):/opt/local/work/mysql-4.1-runtime
-
- 14 May, 2007 14 commits
-
-
unknown authored
into mockturtle.local:/home/dlenev/src/mysql-5.1-cts-3
-
unknown authored
TABLES" and failures of alter_table.test on Windows which occured after pushing fix for bugs #20662, #20903, #24508, #24738 (various problems with CREATE TABLE SELECT). ALTER TABLE statements which were handled using "fast" alter table optimization were not properly working under LOCK TABLES if table was transactional (for all table types under Windows). Code implementing "fast" version of ALTER TABLE tried to open and lock table using open_ltable() after renaming .FRM files (which corresponds to renaming tables in normal case) in some cases (for transactional tables or on Windows). This caused problems under LOCK TABLES and conflicted with name-lock taken by ALTER TABLE RENAME on target tables. This patch solves this issue by using reopen_name_locked_table() instead of open_ltable(). mysql-test/include/mix1.inc: Added test for bug #28415 "Some ALTER TABLE statements no longer work under LOCK TABLES" and minimal coverage for fast ALTER TABLE behaviour for transactional tables. mysql-test/r/innodb_mysql.result: Added test for bug #28415 "Some ALTER TABLE statements no longer work under LOCK TABLES" and minimal coverage for fast ALTER TABLE behaviour for transactional tables. sql/sql_table.cc: mysql_alter_table(): Fixed handling of transactional tables (and all tables on Windows) by "fast" ALTER TABLE. Code implementing "fast" version of ALTER TABLE tried to open and lock table using open_ltable() after renaming .FRM files (which corresponds to renaming tables in normal case) for such tables. This caused problems under LOCK TABLES and conflicted with name-lock taken by ALTER TABLE RENAME on target tables. We solve this issue by using reopen_name_locked_table() instead of open_ltable().
-
unknown authored
into trift2.:/MySQL/M51/push-5.1
-
unknown authored
into trift2.:/MySQL/M51/push-5.1
-
unknown authored
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build configure.in: null merge
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build
-
unknown authored
-
unknown authored
-
unknown authored
-
unknown authored
-
unknown authored
-
unknown authored
into vajra.(none):/opt/local/work/mysql-5.1-runtime sql/sql_insert.cc: Manual merge.
-
unknown authored
sql/sql_insert.cc: Fix a compile-time warning (log_on is not used in embedded).
-
- 12 May, 2007 6 commits
-
-
unknown authored
into bk-internal.mysql.com:/data0/bk/mysql-5.1-opt sql/field.cc: Auto merged
-
unknown authored
into bk-internal.mysql.com:/data0/bk/mysql-5.0-opt
-
unknown authored
into olga.mysql.com:/home/igor/mysql-5.1-opt mysql-test/r/subselect3.result: Auto merged sql/item_subselect.cc: Auto merged sql/sql_select.h: Auto merged
-
unknown authored
-
unknown authored
into olga.mysql.com:/home/igor/mysql-5.1-opt mysql-test/t/grant.test: Auto merged mysql-test/r/grant.result: Manual merge
-
unknown authored
a crash when the left operand of the predicate is evaluated to NULL. It happens when the rows from the inner tables (tables from the subquery) are accessed by index methods with key values obtained by evaluation of the left operand of the subquery predicate. When this predicate is evaluated to NULL an alternative access with full table scan is used to check whether the result set returned by the subquery is empty or not. The crash was due to the fact the info about the access methods used for regular key values was not properly restored after a switch back from the full scan access method had occurred. The patch restores this info properly. The same problem existed for queries with IN subquery predicates if they were used not at the top level of the queries. mysql-test/r/subselect3.result: Added a test case for bug #28375. mysql-test/t/subselect3.test: Added a test case for bug #28375. sql/item_subselect.cc: Fixed bug #28375: a query with an NOT IN subquery predicate may cause a crash when the left operand of the predicate is evaluated to NULL. It happens when the rows from the inner tables (tables from the subquery) are accessed by index methods with key values obtained by evaluation of the left operand of the subquery predicate. When this predicate is evaluated to NULL an alternative access with full table scan is used to check whether the result set returned by the subquery is empty or not. The crash was due to the fact the info about the access methods used for regular key values was not properly restored after a switch back from the full scan access method had occurred. The patch restores this info properly. sql/sql_select.h: Fixed bug #28375: a query with an NOT IN subquery predicate may cause a crash when the left operand of the predicate is evaluated to NULL. In the JOIN_TAB structure two fields have been added to save info about index methods used to access the subquery rows. The saved info is used after a switch back from the alternative full scan access method has occurred. The full scan is used when the left operand of the subquery predicate is evaluated to NULL.
-
- 11 May, 2007 2 commits