An error occurred fetching the project authors.
- 10 Apr, 2009 1 commit
-
-
Chad MILLER authored
comment can't be read back A change to the lexer in 5.1 caused slash-asterisk-bang-version sections to be terminated early if there exists a slash-asterisk- style comment inside it. Nesting comments is usually illegal, but we rely on versioned comment blocks in mysqldump, and the contents of those sections must be allowed to have comments. The problem was that when encountering open-comment tokens and consuming -or- passing through the contents, the "in_comment" state at the end was clobbered with the not-in-a-comment value, regardless of whether we were in a comment before this or not. So, """/*!VER one /* two */ three */""" would lose its in-comment state between "two" and "three". Save the echo and in-comment state, and restore it at the end of the comment if we consume a comment.
-
- 03 Apr, 2009 1 commit
-
-
Davi Arnaut authored
The problem is that a SELECT .. FOR UPDATE statement might open a table and later wait for a impeding global read lock without noticing whether it is holding a table that is being waited upon the the flush phase of the process that took the global read lock. The same problem also affected the following statements: LOCK TABLES .. WRITE UPDATE .. SET (update and multi-table update) TRUNCATE TABLE .. LOAD DATA .. The solution is to make the above statements wait for a impending global read lock before opening the tables. If there is no impending global read lock, the statement raises a temporary protection against global read locks and progresses smoothly towards completion. Important notice: the patch does not try to address all possible cases, only those which are common and can be fixed unintrusively enough for 5.0.
-
- 05 Mar, 2009 1 commit
-
-
Kristofer Pettersson authored
An unnecessarily restrictive lock were taken on sub-SELECTs during DELETE. During parsing, a global structure is reused for sub-SELECTs and the attribute keeping track of lock options were not reset properly. This patch introduces a new attribute to keep track on the syntactical lock option elements found in a sub-SELECT and then sets the lock options accordingly. Now the sub-SELECTs will try to acquire a READ lock if possible instead of a WRITE lock as inherited from the outer DELETE statement.
-
- 10 Feb, 2009 1 commit
-
-
Ignacio Galarza authored
- Remove bothersome warning messages. This change focuses on the warnings that are covered by the ignore file: support-files/compiler_warnings.supp. - Strings are guaranteed to be max uint in length
-
- 16 Dec, 2008 1 commit
-
-
Davi Arnaut authored
Related to operator precedence and associativity. Make the expressions as explicit as possible.
-
- 10 Nov, 2008 1 commit
-
-
Build Team authored
since Oct 1st
-
- 15 Oct, 2008 1 commit
-
-
Davi Arnaut authored
The problem is that the offset argument of the limit clause might be truncated on a 32-bits server built without big tables support. The truncation was happening because the original 64-bits long argument was being cast to a 32-bits (ha_rows) offset counter. The solution is to check if the conversing resulted in value truncation and if so, the offset is set to the maximum possible value that can fit on the type.
-
- 07 Oct, 2008 1 commit
-
-
Gleb Shchepa authored
``FLUSH TABLES WITH READ LOCK'' Concurrent execution of 1) multitable update with a NATURAL/USING join and 2) a such query as "FLUSH TABLES WITH READ LOCK" or "ALTER TABLE" of updating table led to a server crash. The mysql_multi_update_prepare() function call is optimized to lock updating tables only, so it postpones locking to the last, and if locking fails, it does cleanup of modified syntax structures and repeats a query analysis. However, that cleanup procedure was incomplete for NATURAL/USING join syntax data: 1) some Field_item items pointed into freed table structures, and 2) the TABLE_LIST::join_columns fields was not reset. Major change: short-living Field *Natural_join_column::table_field has been replaced with long-living Item*.
-
- 18 Sep, 2008 1 commit
-
-
Gleb Shchepa authored
columns data types The "SELECT @lastId, @lastId := Id FROM t" query returns different result sets depending on the type of the Id column (INT or BIGINT). Note: this fix doesn't cover the case when a select query references an user variable and stored function that updates a value of that variable, in this case a result is indeterminate. The server uses incorrect assumption about a constantness of an user variable value as a select list item: The server caches a last query number where that variable was changed and compares this number with a current query number. If these numbers are different, the server guesses, that the variable is not updating in the current query, so a respective select list item is a constant. However, in some common cases the server updates cached query number too late. The server has been modified to memorize user variable assignments during the parse phase to take them into account on the next (query preparation) phase independently of the order of user variable references/assignments in a select item list.
-
- 14 Jul, 2008 1 commit
-
-
Marc Alff authored
build) The crash was caused by freeing the internal parser stack during the parser execution. This occured only for complex stored procedures, after reallocating the parser stack using my_yyoverflow(), with the following C call stack: - MYSQLparse() - any rule calling sp_head::restore_lex() - lex_end() - x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs) The root cause is the implementation of stored procedures, which breaks the assumption from 4.1 that there is only one LEX structure per parser call. The solution is to separate the LEX structure into: - attributes that represent a statement (the current LEX structure), - attributes that relate to the syntax parser itself (Yacc_state), so that parsing multiple statements in stored programs can create multiple LEX structures while not changing the unique Yacc_state. Now, Yacc_state and the existing Lex_input_stream are aggregated into Parser_state, a structure that represent the complete state of the (Lexical + Syntax) parser.
-
- 07 Jul, 2008 1 commit
-
-
Marc Alff authored
enabled) Before this fix, the lexer and parser would treat the ';' character as a different token (either ';' or END_OF_INPUT), based on convoluted logic, which failed in simple cases where a stored procedure is implemented as a single statement, and used in a multi query. With this fix: - the character ';' is always parsed as a ';' token in the lexer, - parsing multi queries is implemented in the parser, in the 'query:' rules, - the value of thd->client_capabilities, which is the capabilities negotiated between the client and the server during bootstrap, is immutable and not arbitrarily modified during parsing (which was the root cause of the bug)
-
- 27 Mar, 2008 1 commit
-
-
evgen@moonbone.local authored
Mixing aggregate functions and non-grouping columns is not allowed in the ONLY_FULL_GROUP_BY mode. However in some cases the error wasn't thrown because of insufficient check. In order to check more thoroughly the new algorithm employs a list of outer fields used in a sum function and a SELECT_LEX::full_group_by_flag. Each non-outer field checked to find out whether it's aggregated or not and the current select is marked accordingly. All outer fields that are used under an aggregate function are added to the Item_sum::outer_fields list and later checked by the Item_sum::check_sum_func function.
-
- 22 Feb, 2008 1 commit
-
-
anozdrin/alik@quad. authored
between 5.0 and 5.1. The problem was that in the patch for Bug#11986 it was decided to store original query in UTF8 encoding for the INFORMATION_SCHEMA. This approach however turned out to be quite difficult to implement properly. The main problem is to preserve the same IS-output after dump/restore. So, the fix is to rollback to the previous functionality, but also to fix it to support multi-character-set-queries properly. The idea is to generate INFORMATION_SCHEMA-query from the item-tree after parsing view declaration. The IS-query should: - be completely in UTF8; - not contain character set introducers. For more information, see WL4052.
-
- 05 Nov, 2007 1 commit
-
-
istruewing@stella.local authored
partitioned table Trying INSERT DELAYED on a partitioned table, that has not been used right before, crashes the server. When a table is used for select or update, it is kept open for some time. This period I mean with "right before". Information about partitioning of a table is stored in form of a string in the .frm file. Parsing of this string requires a correctly set up lexical analyzer (lex). The partitioning code uses a new temporary instance of a lex. But it does still refer to the previously active lex. The delayd insert thread does not initialize its lex though... Added initialization for thd->lex before open table in the delayed thread and at all other places where it is necessary to call lex_start() if all tables would be partitioned and need to parse the .frm file.
-
- 09 Oct, 2007 1 commit
-
-
Problem: creating a partitioned table during name resolution for the partition function we search for column names in all parts of the CREATE TABLE query. It is superfluous (and wrong) sometimes. Fix: launch name resolution for the partition function against the table we're creating.
-
- 19 Sep, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
The parser uses ulonglong to store the LIMIT number. This number then is stored into a variable of type ha_rows. ha_rows is either 4 or 8 byte depending on the BIG_TABLES define from config.h So an overflow may occur (and LIMIT becomes zero) while storing an ulonglong value in ha_rows. Fixed by : 1. Using the maximum possible value for ha_rows on overflow 2. Defining BIG_TABLES for the windows builds (to match the others)
-
- 30 Aug, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
comments) This change set is for 5.1 (manually merged) Before this fix, the server would accept queries that contained comments, even when the comments were not properly closed with a '*' '/' marker. For example, select 1 /* + 2 <EOF> would be accepted as select 1 /* + 2 */ <EOF> and executed as select 1 With this fix, the server now rejects queries with unclosed comments as syntax errors. Both regular comments ('/' '*') and special comments ('/' '*' '!') must be closed with '*' '/' to be parsed correctly.
-
- 29 Aug, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
comments) Before this fix, the server would accept queries that contained comments, even when the comments were not properly closed with a '*' '/' marker. For example, select 1 /* + 2 <EOF> would be accepted as select 1 /* + 2 */ <EOF> and executed as select 1 With this fix, the server now rejects queries with unclosed comments as syntax errors. Both regular comments ('/' '*') and special comments ('/' '*' '!') must be closed with '*' '/' to be parsed correctly.
-
- 23 Aug, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
Recommit to 5.1.22. The bug caused memory corruption for some queries with top OR level in the WHERE condition if they contained equality predicates and other sargable predicates in disjunctive parts of the condition. The corruption happened because the upper bound of the memory allocated for KEY_FIELD and SARGABLE_PARAM internal structures containing info about potential lookup keys was calculated incorrectly in some cases. In particular it was calculated incorrectly when the WHERE condition was an OR formula with disjuncts being AND formulas including equalities and other sargable predicates.
-
- 22 Aug, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
Before this patch, the parser would execute: - Select->expr_list.push_front() - Select->expr_list.pop() when parsing expressions lists, in the following rules: - udf_expr_list - expr_list - ident_list This is unnecessary, and introduces overhead due to the memory allocations performed with Select->expr_list With this patch, this code has been removed. The list being parsed is maintained in the parser stack instead. Also, 'udf_expr_list' has been renamed 'opt_udf_expr_list', since this production can be empty.
-
- 16 Aug, 2007 1 commit
-
-
kostja@bodhi.(none) authored
-
- 15 Aug, 2007 2 commits
-
-
igor@olga.mysql.com authored
The bug caused memory corruption for some queries with top OR level in the WHERE condition if they contained equality predicates and other sargable predicates in disjunctive parts of the condition. The corruption happened because the upper bound of the memory allocated for KEY_FIELD and SARGABLE_PARAM internal structures containing info about potential lookup keys was calculated incorrectly in some cases. In particular it was calculated incorrectly when the WHERE condition was an OR formula with disjuncts being AND formulas including equalities and other sargable predicates.
-
kostja@bodhi.(none) authored
-
- 13 Aug, 2007 1 commit
-
-
monty@mysql.com/nosik.monty.fi authored
Faster thr_alarm() Added 'Opened_files' status variable to track calls to my_open() Don't give warnings when running mysql_install_db Added option --source-install to mysql_install_db I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems index_read() -> index_read_map() index_read_idx() -> index_read_idx_map() index_read_last() -> index_read_last_map()
-
- 03 Aug, 2007 1 commit
-
-
bar@mysql.com/bar.myoffice.izhnet.ru authored
(Regression, caused by a patch for the bug 22646). Problem: when result type of date_format() was changed from binary string to character string, mixing date_format() with a ascii column in CONCAT() stopped to work. Fix: - adding "repertoire" flag into DTCollation class, to mark items which can return only pure ASCII strings. - allow character set conversion from pure ASCII to other character sets.
-
- 29 Jul, 2007 2 commits
-
-
thek@adventure.(none) authored
- Removed unused variable.
-
thek@adventure.(none) authored
- Removed unused variable.
-
- 27 Jul, 2007 1 commit
-
-
thek@adventure.(none) authored
When a table was explicitly locked with LOCK TABLES no associated tables from any related trigger on the subject table were locked. As a result of this the user could experience unexpected locking behavior and statement failures similar to "failed: 1100: Table'xx' was not locked with LOCK TABLES". This patch fixes this problem by making sure triggers are pre-loaded on any statement if the subject table was explicitly locked with LOCK TABLES.
-
- 23 Jul, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
-
- 20 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
-
- 16 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
-
- 12 Jul, 2007 1 commit
-
-
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.
-
- 06 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
The need arose when working on Bug 26141, where it became necessary to replace TABLE_LIST with its forward declaration in a few headers, and this involved a lot of s/TABLE_LIST/st_table_list/. Although other workarounds exist, this patch is in line with our general strategy of moving away from typedef-ed names. Sometime in future we might also rename TABLE_LIST to follow the coding style, but this is a huge change.
-
- 05 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
fails if a database is not selected prior. The problem manifested itself when a user tried to create a routine that had non-fully-qualified identifiers in its bodies and there was no current database selected. This is a regression introduced by the fix for Bug 19022: The patch for Bug 19022 changes the code to always produce a warning if we can't resolve the current database in the parser. In this case this was not necessary, since even though the produced parsed tree was incorrect, we never re-use sphead that was obtained at first parsing of CREATE PROCEDURE. The sphead that is anyhow used is always obtained through db_load_routine, and there we change the current database to sphead->m_db before calling yyparse. The idea of the fix is to resolve the current database directly using lex->sphead->m_db member when parsing a stored routine body, when such is present. This patch removes the need to reset the current database when loading a trigger or routine definition into SP cache. The redundant code will be removed in 5.1.
-
- 29 Jun, 2007 2 commits
-
-
anozdrin/alik@ibm. authored
-
anozdrin/alik@ibm. authored
1. Fix ddl_i18n_koi8r, ddl_i18n_utf8: explicitly specify character-sets directory for mysqldump; 2. Fix crash in mysqldump if collation is not found; 3. Use proper way to compare character set names.
-
- 28 Jun, 2007 1 commit
-
-
anozdrin/alik@ibm. authored
- BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
-
- 12 Jun, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
Bug 28127 (Some valid identifiers names are not parsed correctly) Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func) This patch is the second part of a major cleanup, required to fix Bug 25411 (trigger code truncated). The root cause of the issue stems from the function skip_rear_comments, which was a work around to remove "extra" "*/" characters from the query text, when parsing a query and reusing the text fragments to represent a view, trigger, function or stored procedure. The reason for this work around is that "special comments", like /*!50002 XXX */, were not parsed properly, so that a query like: AAA /*!50002 BBB */ CCC would be seen by the parser as "AAA BBB */ CCC" when the current version is greater or equal to 5.0.2 The root cause of this stems from how special comments are parsed. Special comments are really out-of-bound text that appear inside a query, that affects how the parser behave. In nature, /*!50002 XXX */ in MySQL is similar to the C concept of preprocessing : #if VERSION >= 50002 XXX #endif Depending on the current VERSION of the server, either the special comment should be expanded or it should be ignored, but in all cases the "text" of the query should be re-written to strip the "/*!50002" and "*/" markers, which does not belong to the SQL language itself. Prior to this fix, these markers would leak into : - the storage format for VIEW, - the storage format for FUNCTION, - the storage format for FUNCTION parameters, in mysql.proc (param_list), - the storage format for PROCEDURE, - the storage format for PROCEDURE parameters, in mysql.proc (param_list), - the storage format for TRIGGER, - the binary log used for replication. In all cases, not only this cause format corruption, but also provide a vector for dormant security issues, by allowing to tunnel code that will be activated after an upgrade. The proper solution is to deal with special comments strictly during parsing, when accepting a query from the outside world. Once a query is parsed and an object is created with a persistant representation, this object should not arbitrarily mutate after an upgrade. In short, special comments are a useful but limited feature for MYSQLdump, when used at an *interface* level to facilitate import/export, but bloating the server *internal* storage format is *not* the proper way to deal with configuration management of the user logic. With this fix: - the Lex_input_stream class now acts as a comment pre-processor, and either expands or ignore special comments on the fly. - MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the public interface of Lex_input_stream. In particular, how the input stream accepts or rejects a character is private to Lex_input_stream, and the internal buffer pointers of that class are strictly private, and should not be tempered with during parsing. This caused many changes mostly in sql_lex.cc. During the code cleanup in case MY_LEX_NUMBER_IDENT, Bug 28127 (Some valid identifiers names are not parsed correctly) was found and fixed. By parsing special comments properly, and removing the function 'skip_rear_comments' [sic], Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func) has been fixed as well.
-
- 10 Jun, 2007 1 commit
-
-
kostja@bodhi.(none) authored
Coding style: classes start with a capital letter. Rename some classes related to parsing: create_field -> Create_field foreign_key -> Foreign_key key_part_spec -> Key_part_spec
-
- 04 Jun, 2007 1 commit
-
-
igor@olga.mysql.com authored
-