An error occurred fetching the project authors.
- 29 Jan, 2010 1 commit
-
-
Andrei Elkin authored
The auto-inc unsafe warning makes sense even though it's just one auto-inc table could be involved via a trigger or a stored function. However its content was not updated by bug@45677 fixes continuing to mention two tables whereas the fixes refined semantics of replication of auto_increment in stored routine. Fixed with updating the error message, renaming the error and an internal unsafe-condition constants. A documentation notice ====================== Inserting into an autoincrement column in a stored function or a trigger is unsafe for replication. Even with just one autoincrement column, if the routine is invoked more than once slave is not guaranteed to execute the statement graph same way as the master. And since it's impossible to estimate how many times a routine can be invoked at the query pre-execution phase (see lock_tables), the statement is marked pessimistically unsafe.
-
- 27 Nov, 2009 1 commit
-
-
Tor Didriksen authored
-
- 03 Nov, 2009 1 commit
-
-
Alfranio Correia authored
Non-transactional updates that take place inside a transaction present problems for logging because they are visible to other clients before the transaction is committed, and they are not rolled back even if the transaction is rolled back. It is not always possible to log correctly in statement format when both transactional and non-transactional tables are used in the same transaction. In the current patch, we ensure that such scenario is completely safe under the ROW and MIXED modes.
-
- 02 Nov, 2009 1 commit
-
-
Marc Alff authored
Backport for 5.5 The root cause of this bug is that the grammar for GROUP BY clauses, when using WITH CUBE or WITH ROLLUP, cause conflicts with the grammar for VIEW, when using WITH CHECK OPTION. The solution is to implement two token look ahead when parsing a WITH token, to disambiguate the non standard WITH CUBE and WITH ROLLUP syntaxes. Patch based on code from Marc Alff and Antony Curtis
-
- 21 Oct, 2009 1 commit
-
-
Konstantin Osipov authored
2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29, 2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and some other minor revisions. This patch implements: WL#4264 "Backup: Stabilize Service Interface" -- all the server prerequisites except si_objects.{h,cc} themselves (they can be just copied over, when needed). WL#4435: Support OUT-parameters in prepared statements. (and all issues in the initial patches for these two tasks, that were discovered in pushbuild and during testing). Bug#39519: mysql_stmt_close() should flush all data associated with the statement. After execution of a prepared statement, send OUT parameters of the invoked stored procedure, if any, to the client. When using the binary protocol, send the parameters in an additional result set over the wire. When using the text protocol, assign out parameters to the user variables from the CALL(@var1, @var2, ...) specification. The following refactoring has been made: - Protocol::send_fields() was renamed to Protocol::send_result_set_metadata(); - A new Protocol::send_result_set_row() was introduced to incapsulate common functionality for sending row data. - Signature of Protocol::prepare_for_send() was changed: this operation does not need a list of items, the number of items is fully sufficient. The following backward incompatible changes have been made: - CLIENT_MULTI_RESULTS is now enabled by default in the client; - CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.
-
- 16 Oct, 2009 1 commit
-
-
Mikael Ronstrom authored
-
- 14 Oct, 2009 3 commits
-
-
Konstantin Osipov authored
---------------------------------------------------------- revno: 2617.22.5 committer: Konstantin Osipov <kostja@sun.com> branch nick: mysql-6.0-runtime timestamp: Tue 2009-01-27 05:08:48 +0300 message: Remove non-prefixed use of HASH. Always use my_hash_init(), my_hash_inited(), my_hash_search(), my_hash_element(), my_hash_delete(), my_hash_free() rather than non-prefixed counterparts (hash_init(), etc). Remove the backward-compatible defines.
-
Sven Sandberg authored
Post-push fix. Problem: After the original bugfix, if a statement is unsafe, binlog_format=mixed, and engine is statement-only, a warning was generated and the statement executed. However, it is a fundamental principle of binlogging that binlog_format=mixed should guarantee correct logging, no compromise. So correct behavior is to generate an error and don't execute the statement. Fix: Generate error instead of warning. Since issue_unsafe_warnings can only generate one error message, this allows us to simplify the code a bit too: decide_logging_format does not have to save the error code for issue_unsafe_warnings
-
Konstantin Osipov authored
---------------------------------------------------------- revno: 2630.22.8 committer: Konstantin Osipov <konstantin@mysql.com> branch nick: mysql-6.0-runtime timestamp: Sun 2008-08-10 18:49:52 +0400 message: Get rid of typedef struct for the most commonly used types: TABLE, TABLE_SHARE, LEX. This simplifies use of tags and forward declarations.
-
- 09 Oct, 2009 1 commit
-
-
Dmitry Lenev authored
storing and restoring information about foreign keys in the .FRM files and properly displaying it in SHOW CREATE TABLE output and I_S tables. The idea of this patch is to change type of Key_part_spec::field_name and Key::name to LEX_STRING in order to avoid extra strlen() calls during semantic analysis and statement execution, particularly, in code to be implemented on the 2nd milestone of WL#148. Note that since we are not using LEX_STRING everywhere yet (e.g. in Create_field and KEY) and we want to limit scope of our changes we have to do strlen() in places where we create Key and Key_part_spec instances from objects using plain (char*) for strings. These calls will go away during the process of further (char*) -> LEX_STRING refactoring. We have introduced these changes in 6.0 and backported them to 5.5 tree to make people aware of these changes as early as possible and to simplify merges with mysql-fk and mysql-6.1-fk trees. No test case is needed since this patch does not introduce any user visible changes.
-
- 01 Oct, 2009 1 commit
-
-
Mikael Ronstrom authored
Changed all no_ to num_ to avoid strange names like no_list_values which is not expected to be number of list values, rather a boolea indicating no list values
-
- 17 Sep, 2009 1 commit
-
-
Staale Smedseng authored
with gcc 4.3.2 This is the fifth patch cleaning up more GCC warnings about variables used before initialized using the new macro UNINIT_VAR().
-
- 15 Sep, 2009 1 commit
-
-
Mikael Ronstrom authored
WL#3352, Introducing Column list partitioning, makes it possible to partition on most data types, makes it possible to prune on multi-field partitioning
-
- 08 Aug, 2009 1 commit
-
-
Davi Arnaut authored
The problem is that the lexer could inadvertently skip over the end of a query being parsed if it encountered a malformed multibyte character. A specially crated query string could cause the lexer to jump up to six bytes past the end of the query buffer. Another problem was that the laxer could use unfiltered user input as a signed array index for the parser maps (having upper and lower bounds 0 and 256 respectively). The solution is to ensure that the lexer only skips over well-formed multibyte characters and that the index value of the parser maps is always a unsigned value.
-
- 24 Jun, 2009 1 commit
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2852.2.3 > revision-id: davi.arnaut@sun.com-20090403194600-60ufn0tz1gx1kl0l > parent: gni@mysql.com-20090403184200-vnjtpsv4an79w8bu > parent: davi.arnaut@sun.com-20090403191154-0ho2nai3chjsmpof > committer: Davi Arnaut <Davi.Arnaut@Sun.COM> > branch nick: 43230-5.1 > timestamp: Fri 2009-04-03 16:46:00 -0300 > message: > Merge Bug#43230 into mysql-5.1-bugteam > ------------------------------------------------------------ > revno: 1810.3855.16 > revision-id: davi.arnaut@sun.com-20090403191154-0ho2nai3chjsmpof > parent: chad@mysql.com-20090402152928-3ld60a56h86njcpg > committer: Davi Arnaut <Davi.Arnaut@Sun.COM> > branch nick: 43230-5.0 > timestamp: Fri 2009-04-03 16:11:54 -0300 > message: > Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely > > 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.
-
- 17 Jun, 2009 1 commit
-
-
Staale Smedseng authored
with gcc 4.3.2 Compiling MySQL with gcc 4.3.2 and later produces a number of warnings, many of which are new with the recent compiler versions. This bug will be resolved in more than one patch to limit the size of changesets. This is the second patch, fixing more of the warnings.
-
- 10 Jun, 2009 1 commit
-
-
Staale Smedseng authored
with gcc 4.3.2 Compiling MySQL with gcc 4.3.2 and later produces a number of warnings, many of which are new with the recent compiler versions. This bug will be resolved in more than one patch to limit the size of changesets. This is the second patch, fixing more of the warnings.
-
- 27 May, 2009 1 commit
-
-
Georgi Kodinov authored
Added a more detailed error message on calling an ambiguous missing function.
-
- 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 1 commit
-
-
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.
-