An error occurred fetching the project authors.
- 28 May, 2007 1 commit
-
-
thek@adventure.(none) authored
- A race condition caused brief unavailablility when trying to acccess a table. - The variable 'grant_option' was removed to resolve the race condition and to simplify the design pattern. This flag was originally intended to optimize grant checks.
-
- 23 May, 2007 2 commits
-
-
dlenev@mockturtle.local authored
Bug #23667 "CREATE TABLE LIKE is not isolated from alteration by other connections" Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open" As well as: Bug #25578 "CREATE TABLE LIKE does not require any privileges on source table". The first and the second bugs resulted in various errors and wrong binary log order when one tried to execute concurrently CREATE TABLE LIKE statement and DDL statements on source table or DML/DDL statements on its target table. The problem was caused by incomplete protection/table-locking against concurrent statements implemented in mysql_create_like_table() routine. We solve it by simply implementing such protection in proper way. Most of actual work for 5.1 was already done by fix for bug 20662 and preliminary patch changing locking in ALTER TABLE. The third bug allowed user who didn't have any privileges on table create its copy and therefore circumvent privilege check for SHOW CREATE TABLE. This patch solves this problem by adding privilege check, which was missing. Finally it also removes some duplicated code from mysql_create_like_table() and thus fixes bug #26869 "TABLE_LIST::table_name_length inconsistent with TABLE_LIST::table_name".
-
dlenev@mockturtle.local authored
Bug #23667 "CREATE TABLE LIKE is not isolated from alteration by other connections" Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open" As well as: Bug #25578 "CREATE TABLE LIKE does not require any privileges on source table". The first and the second bugs resulted in various errors and wrong binary log order when one tried to execute concurrently CREATE TABLE LIKE statement and DDL statements on source table or DML/DDL statements on its target table. The problem was caused by incomplete protection/table-locking against concurrent statements implemented in mysql_create_like_table() routine. We solve it by simply implementing such protection in proper way (see comment for sql_table.cc for details). The third bug allowed user who didn't have any privileges on table create its copy and therefore circumvent privilege check for SHOW CREATE TABLE. This patch solves this problem by adding privilege check, which was missing. Finally it also removes some duplicated code from mysql_create_like_table(). Note that, altough tests covering concurrency-related aspects of CREATE TABLE LIKE behaviour will only be introduced in 5.1, they were run manually for this patch as well.
-
- 19 May, 2007 1 commit
-
-
dlenev@mockturtle.local authored
and invalidation in the most general case (non-temporary table and not simple RENAME or ENABLE/DISABLE KEYS or partitioning command). See comment for sql/sql_table.cc for more information. These changes are prerequisite for 5.1 version of fix for bug #23667 "CREATE TABLE LIKE is not isolated from alteration by other connections"
-
- 11 May, 2007 2 commits
-
-
dlenev@mockturtle.local authored
Bug #20662 "Infinite loop in CREATE TABLE IF NOT EXISTS ... SELECT with locked tables" Bug #20903 "Crash when using CREATE TABLE .. SELECT and triggers" Bug #24738 "CREATE TABLE ... SELECT is not isolated properly" Bug #24508 "Inconsistent results of CREATE TABLE ... SELECT when temporary table exists" Deadlock occured when one tried to execute CREATE TABLE IF NOT EXISTS ... SELECT statement under LOCK TABLES which held read lock on target table. Attempt to execute the same statement for already existing target table with triggers caused server crashes. Also concurrent execution of CREATE TABLE ... SELECT statement and other statements involving target table suffered from various races (some of which might've led to deadlocks). Finally, attempt to execute CREATE TABLE ... SELECT in case when a temporary table with same name was already present led to the insertion of data into this temporary table and creation of empty non-temporary table. All above problems stemmed from the old implementation of CREATE TABLE ... SELECT in which we created, opened and locked target table without any special protection in a separate step and not with the rest of tables used by this statement. This underminded deadlock-avoidance approach used in server and created window for races. It also excluded target table from prelocking causing problems with trigger execution. The patch solves these problems by implementing new approach to handling of CREATE TABLE ... SELECT for base tables. We try to open and lock table to be created at the same time as the rest of tables used by this statement. If such table does not exist at this moment we create and place in the table cache special placeholder for it which prevents its creation or any other usage by other threads. We still use old approach for creation of temporary tables. Note that we have separate fix for 5.0 since there we use slightly different less intrusive approach.
-
dlenev@mockturtle.local authored
Bug #20662 "Infinite loop in CREATE TABLE IF NOT EXISTS ... SELECT with locked tables" Bug #20903 "Crash when using CREATE TABLE .. SELECT and triggers" Bug #24738 "CREATE TABLE ... SELECT is not isolated properly" Bug #24508 "Inconsistent results of CREATE TABLE ... SELECT when temporary table exists" Deadlock occured when one tried to execute CREATE TABLE IF NOT EXISTS ... SELECT statement under LOCK TABLES which held read lock on target table. Attempt to execute the same statement for already existing target table with triggers caused server crashes. Also concurrent execution of CREATE TABLE ... SELECT statement and other statements involving target table suffered from various races (some of which might've led to deadlocks). Finally, attempt to execute CREATE TABLE ... SELECT in case when a temporary table with same name was already present led to the insertion of data into this temporary table and creation of empty non-temporary table. All above problems stemmed from the old implementation of CREATE TABLE ... SELECT in which we created, opened and locked target table without any special protection in a separate step and not with the rest of tables used by this statement. This underminded deadlock-avoidance approach used in server and created window for races. It also excluded target table from prelocking causing problems with trigger execution. The patch solves these problems by implementing new approach to handling of CREATE TABLE ... SELECT for base tables. We try to open and lock table to be created at the same time as the rest of tables used by this statement. If such table does not exist at this moment we create and place in the table cache special placeholder for it which prevents its creation or any other usage by other threads. We still use old approach for creation of temporary tables. Also note that we decided to postpone introduction of some tests for concurrent behaviour of CREATE TABLE ... SELECT till 5.1. The main reason for this is absence in 5.0 ability to set @@debug variable at runtime, which can be circumvented only by using several test files with individual .opt files. Since the latter is likely to slowdown test-suite unnecessary we chose not to push this tests into 5.0, but run them manually for this version and later push their optimized version into 5.1
-
- 08 May, 2007 2 commits
-
-
thek@adventure.(none) authored
-
thek@adventure.(none) authored
- Queries in the query cache are identified by the individual characters in the query statement, the current database and the current environment expressed as a set of system variable flags. - Since the set of environment flags didn't properly describe the current environment unexpected results were returned from the query cache. - Query cache is now cleared when the variable ft_boolean_syntax is updated. - An identification flag for the variable default_week_format is added to the query cache record. Thanks to Martin Friebe who has supplied significant parts of this patch.
-
- 04 May, 2007 1 commit
-
-
evgen@moonbone.local authored
The LEAST/GREATEST functions compared DATE/DATETIME values as strings which in some cases could lead to a wrong result. A new member function called cmp_datetimes() is added to the Item_func_min_max class. It compares arguments in DATETIME context and returns index of the least/greatest argument. The Item_func_min_max::fix_length_and_dec() function now detects when arguments should be compared in DATETIME context and sets the newly added flag compare_as_dates. It indicates that the cmp_datetimes() function should be called to get a correct result. Item_func_min_max::val_xxx() methods are corrected to call the cmp_datetimes() function when needed. Objects of the Item_splocal class now stores and reports correct original field type.
-
- 30 Apr, 2007 1 commit
-
-
serg@sergbook.mysql.com authored
-
- 28 Apr, 2007 1 commit
-
-
kaa@polly.local authored
Fix for bug #24912 "problems with bigint in abs() ceiling() round() truncate() mod()" and a number of related problems: - unsigned flag was not handled correctly for a number of mathematical funcions, which led to incorrect results - passing large values as the number of decimals to ROUND() resulted in incorrect results and even server crashes in some cases - reverted the fix and the testcase for bug #10083 as it violates the manual - fixed some testcases which relied on broken ROUND() behavior
-
- 26 Apr, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
-
- 24 Apr, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
The issue found with bug 25411 is due to the function skip_rear_comments() which damages the source code while implementing a work around. The root cause of the problem is in the lexical analyser, which does not process special comments properly. For special comments like : [1] aaa /*!50000 bbb */ ccc since 5.0 is a version older that the current code, the parser is in lining the content of the special comment, so that the query to process is [2] aaa bbb ccc However, the text of the query captured when processing a stored procedure, stored function or trigger (or event in 5.1), can be after rebuilding it: [3] aaa bbb */ ccc which is wrong. To fix bug 25411 properly, the lexical analyser needs to return [2] when in lining special comments. In order to implement this, some preliminary cleanup is required in the code, which is implemented by this patch. Before this change, the structure named LEX (or st_lex) contains attributes that belong to lexical analysis, as well as attributes that represents the abstract syntax tree (AST) of a statement. Creating a new LEX structure for each statements (which makes sense for the AST part) also re-initialized the lexical analysis phase each time, which is conceptually wrong. With this patch, the previous st_lex structure has been split in two: - st_lex represents the Abstract Syntax Tree for a statement. The name "lex" has not been changed to avoid a bigger impact in the code base. - class lex_input_stream represents the internal state of the lexical analyser, which by definition should *not* be reinitialized when parsing multiple statements from the same input stream. This change is a pre-requisite for bug 25411, since the implementation of lex_input_stream will later improve to deal properly with special comments, and this processing can not be done with the current implementation of sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer. This change set alone does not fix bug 25411.
-
- 18 Apr, 2007 1 commit
-
-
msvensson@pilot.blaudden authored
- Improve mysql_upgrade and add comments describing it's logic - Don't look for mysql and mysqlcheck randomly, use dir where mysql_upgrade was started from - Don't look for mysql_fix_privilege_tables.sql randomly, compile in the mysql_fix_privilege_tables.sql file and use that to upgrade the system tables of MySQL - Check for any unexpected error returned from runnning the mysql_fix_privilege_tables SQL - Fix bug#26639, bug#24248 and bug#25405
-
- 09 Apr, 2007 1 commit
-
-
bar@mysql.com authored
Problem: setting/displaying @@LC_TIME_NAMES didn't distinguish between GLOBAL and SESSION variable types - always SESSION variable was set/shonw. Fix: set either global or session value. Also, "mysqld --lc-time-names" was added to set "global default" value.
-
- 04 Apr, 2007 3 commits
-
-
mskold/marty@mysql.com/linux.site authored
-
mskold/marty@mysql.com/linux.site authored
In certain cases AFTER UPDATE/DELETE triggers on NDB tables that referenced subject table didn't see the results of operation which caused invocation of those triggers. In other words AFTER trigger invoked as result of update (or deletion) of particular row saw version of this row before update (or deletion). The problem occured because NDB handler in those cases postponed actual update/delete operations to be able to perform them later as one batch. This fix solves the problem by disabling this optimization for particular operation if subject table has AFTER trigger for this operation defined. To achieve this we introduce two new flags for handler::extra() method: HA_EXTRA_DELETE_CANNOT_BATCH and HA_EXTRA_UPDATE_CANNOT_BATCH. These are called if there exists AFTER DELETE/UPDATE triggers during a statement that potentially can generate calls to delete_row()/update_row(). This includes multi_delete/multi_update statements as well as insert statements that do delete/update as part of an ON DUPLICATE statement.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
now we return different error message if user doesn't have SELECT grants
-
- 03 Apr, 2007 3 commits
-
-
gluh@mysql.com/eagle.(none) authored
additional fix
-
gluh@mysql.com/eagle.(none) authored
-
anozdrin/alik@ibm.opbmk authored
The problem was that THD::db_access variable was not restored after database switch in stored-routine-execution code. The fix is to restore THD::db_access in this case. Unfortunately, this fix requires additional changes, because in prepare_schema_table(), called on the parsing stage, we checked privileges. That was wrong according to our design, but this flaw haven't struck so far, because it was masked. All privilege checkings must be done on the execution stage in order to be compatible with prepared statements and stored routines. So, this patch also contains patch for prepare_schema_table(), which moves the checkings to the execution phase.
-
- 02 Apr, 2007 1 commit
-
-
antony@ppcg5.local authored
"Plugin Server Variables" Post review cleanups.
-
- 27 Mar, 2007 3 commits
-
-
anozdrin/alik@alik.opbmk authored
execution breaks replication. When a stored routine is executed, we switch current database to the database, in which the routine has been created. When the stored routine finishes, we switch back to the original database. The problem was that if the original database does not exist (anymore) after routine execution, we raised an error. The fix is to report a warning, and switch to the NULL database.
-
kostja@bodhi.local authored
the lexer API which internally uses unsigned char variables to address its state map. The implementation of the lexer should be internal to the lexer, and not influence the rest of the code.
-
kostja@bodhi.local authored
-
- 24 Mar, 2007 2 commits
-
-
aelkin/elkin@andrepl.(none) authored
eliminating the unnecessary option; and replacing site-dependant stuff in the test
-
* Modified Federated memory allocation to use MEM_ROOT * Modified sql_servers and federated to allocate share connection parameters to use MEM_ROOT * Modified Federated to allow tablename in addition to server name * Implicit flushing of tables using altered/dropped server name * Added tests to prove new functionality works Contributors to this patch: Patrick Galbraith, Antony Curtis
-
- 23 Mar, 2007 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
Made year 2000 handling more uniform Removed year 2000 handling out from calc_days() The above removes some bugs in date/datetimes with year between 0 and 200 Now we get a note when we insert a datetime value into a date column For default values to CREATE, don't give errors for warning level NOTE Fixed some compiler failures Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support) Removed duplicate typedef TIME and replaced it with MYSQL_TIME Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE" Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value" Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
-
- 16 Mar, 2007 4 commits
-
-
serg@janus.mylan authored
s/ulonglong/key_part_map/, comments
-
joerg@trift2. authored
- Build sql files for netware from the mysql_system_tables*.sq files - Fix comments about mysql_create_system_tables.sh - Use mysql_install_db.sh to create system tables for mysql_test-run-shell - Fix mysql-test-run.pl to also look in share/mysql for the msyql_system*.sql files Changeset coded today by Magnus Svensson, just the application to 5.0.38 is by Joerg Bruehe.
-
msvensson@pilot.blaudden authored
- Build sql files for netware from the mysql_system_tables*.sq files - Fix comments about mysql_create_system_tables.sh - Use mysql_install_db.sh to create system tables for mysql_test-run-shell - Fix mysql-test-run.pl to also look in share/mysql for the msyql_system*.sql files
-
gkodinov/kgeorge@macbook.gmz authored
INSERT uses query_id to verify what fields are mentioned in the fields list of the INSERT command. However the check for that is made after the ON DUPLICATE KEY is processed. This causes all the fields mentioned in ON DUPLICATE KEY to be considered as mentioned in the fields list of INSERT. Moved the check up, right after processing the fields list.
-
- 09 Mar, 2007 2 commits
-
-
guilhem@gbichot3.local authored
Cache". WL#1569 "Prepared Statements: implement support of Query Cache". Prepared SELECTs did not look up in the query cache, and their results were not stored in the query cache. This made them slower than non-prepared SELECTs in some cases. The fix is to re-use the expanded query (the prepared query where "?" placeholders are replaced by their values, at execution time) for searching/storing in the query cache. It works fine for statements prepared via mysql_stmt_prepare(), which are the most commonly used and were the scope of this bugfix and WL. It works less fine for statements prepared via the SQL command PREPARE...FROM, which are still not using the query cache if they have at least one parameter (because then the expanded query contains names of user variables, and user variables don't work with the query cache, even in non-prepared queries). Note that results from prepared SELECTs, which are in the binary protocol, and results from normal SELECTs, which are in the text protocol, ignore each other in the query cache, because a result in the binary protocol should never be served to a SELECT expecting the text protocol and vice-versa. Note, after this patch, bug 25843 starts applying to query cache ("changing default database between PREPARE and EXECUTE of statement breaks binlog"), we need to fix it.
-
kroki/tomash@moonlight.home authored
The problem was that some facilities (like CONVERT_TZ() function or server HELP statement) may require implicit access to some tables in 'mysql' database. This access was done by ordinary means of adding such tables to the list of tables the query is going to open. However, if we issued LOCK TABLES before that, we would get "table was not locked" error trying to open such implicit tables. The solution is to treat certain tables as MySQL system tables, like we already do for mysql.proc. Such tables may be opened for reading at any moment regardless of any locks in effect. The cost of this is that system table may be locked for writing only together with other system tables, it is disallowed to lock system tables for writing and have any other lock on any other table. After this patch the following tables are treated as MySQL system tables: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc (it already was) mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type These tables are now opened with open_system_tables_for_read() and closed with close_system_tables(), or one table may be opened with open_system_table_for_update() and closed with close_thread_tables() (the latter is used for mysql.proc table, which is updated as part of normal MySQL server operation). These functions may be used when some tables were opened and locked already. NOTE: online update of time zone tables is not possible during replication, because there's no time zone cache flush neither on LOCK TABLES, nor on FLUSH TABLES, so the master may serve stale time zone data from cache, while on slave updated data will be loaded from the time zone tables.
-
- 05 Mar, 2007 3 commits
-
-
gkodinov/kgeorge@macbook.gmz authored
can be specified Currently MySQL allows one to specify what indexes to ignore during join optimization. The scope of the current USE/FORCE/IGNORE INDEX statement is only the FROM clause, while all other clauses are not affected. However, in certain cases, the optimizer may incorrectly choose an index for sorting and/or grouping, and produce an inefficient query plan. This task provides the means to specify what indexes are ignored/used for what operation in a more fine-grained manner, thus making it possible to manually force a better plan. We do this by extending the current IGNORE/USE/FORCE INDEX syntax to: IGNORE/USE/FORCE INDEX [FOR {JOIN | ORDER | GROUP BY}] so that: - if no FOR is specified, the index hint will apply everywhere. - if MySQL is started with the compatibility option --old_mode then an index hint without a FOR clause works as in 5.0 (i.e, the index will only be ignored for JOINs, but can still be used to compute ORDER BY). See the WL#3527 for further details.
-
msvensson@pilot.blaudden authored
-
igor@olga.mysql.com authored
The flag alias_name_used was not set on for the outer references in subqueries. It resulted in replacement of any outer reference resolved against an alias for a full field name when the frm representation of a view with a subquery was generated. If the subquery and the outer query referenced the same table in their from lists this replacement effectively changed the meaning of the view and led to wrong results for selects from this view. Modified several functions to ensure setting the right value of the alias_name_used flag for outer references resolved against aliases.
-
- 02 Mar, 2007 1 commit
-
-
antony@ppcg5.local authored
"Server Variables for Plugins" Implement support for plugins to declare server variables. Demonstrate functionality by removing InnoDB specific code from sql/* New feature for HASH - HASH_UNIQUE flag New feature for DYNAMIC_ARRAY - initializer accepts preallocated ptr. Completed support for plugin reference counting.
-
- 01 Mar, 2007 2 commits
-
-
evgen@moonbone.local authored
When INSERT is done over a view the table being inserted into is checked to be unique among all views tables. But if the view contains self-joined table an error will be thrown even if all tables are used under different aliases. The unique_table() function now also checks tables' aliases when needed.
-
rafal@quant.(none) authored
-