From: Date: November 29 2006 1:52pm Subject: bk commit into 5.0 tree (kroki:1.2303) BUG#20637 List-Archive: http://lists.mysql.com/commits/16103 X-Bug: 20637 Message-Id: <200611291252.kATCq00b007392@moonlight.intranet> Below is the list of changes that have just been committed into a local 5.0 repository of tomash. When tomash does a push these changes will be propagated to the main repository and, within 24 hours after the push, to the public repository. For information on how to access the public repository see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html ChangeSet@stripped, 2006-11-29 15:51:53+03:00, kroki@stripped +1 -0 BUG#20637: "load data concurrent infile" locks the table Note that we ignore CONCURRENT if LOAD DATA CONCURRENT is used from inside a stored routine and MySQL is compiled with Query Cache support (this is not in the manual). The problem was that the condition test of "we are inside stored routine" was reversed, thus CONCURRENT _worked only_ from stored routine. The solution is to use proper condition test. No test case is provided because the test case would require a large amount of input, and it's hard to tell is SELECT is really blocked or just slow (subject to race). sql/sql_yacc.yy@stripped, 2006-11-29 15:51:51+03:00, kroki@stripped +2 -0 Fix the condition of TL_WRITE_CONCURRENT_INSERT on LOAD DATA CONCURRENT, which was reversed, and return valid value if we are in SP. # This is a BitKeeper patch. What follows are the unified diffs for the # set of deltas contained in the patch. The rest of the patch, the part # that BitKeeper cares about, is below these diffs. # User: kroki # Host: moonlight.intranet # Root: /home/tomash/src/mysql_ab/mysql-5.0-bug20637 --- 1.494/sql/sql_yacc.yy 2006-11-29 15:52:00 +03:00 +++ 1.495/sql/sql_yacc.yy 2006-11-29 15:52:00 +03:00 @@ -7031,6 +7031,8 @@ load_data_lock: Ignore this option in SP to avoid problem with query cache */ if (Lex->sphead != 0) + $$= YYTHD->update_lock_default; + else #endif $$= TL_WRITE_CONCURRENT_INSERT; }