If the user has specified --max-connections=N or --table-open-cache=M
options to the server, a warning could be given that some values were
recalculated, and table-open-cache could be assigned greater value.
Note that both warning and increase of table-open-cache were totally
harmless.
This patch fixes recalculation code to ensure that table-open-cache will
be never increased automatically and that a warning will be given only if
some values had to be decreased due to operating system limits.
No test case is provided because we neither can't predict nor control
operating system limits for maximal number of open files.
warnings in sql_trigger.cc and sql_view.cc".
According to the current version of C++ standard offsetof() macro
can't be used for non-POD types. So warnings were emitted when we
tried to use this macro for TABLE_LIST and Table_triggers_list
classes. Note that despite of these warnings it was probably safe
thing to do.
This fix tries to circumvent this limitation by implementing
custom version of offsetof() macro to be used with these
classes. This hack should go away once we will refactor
File_parser class.
Alternative approaches such as disabling this warning for
sql_trigger.cc/sql_view.cc or for the whole server were
considered less explicit. Also I was unable to find a way
to disable particular warning for particular _part_ of
file in GCC.
This patch reverts a change introduced by Bug 6951, which incorrectly
set thd->abort_on_warning for stored procedures.
As per internal discussions about the SQL_MODE=TRADITIONAL,
the correct behavior is to *not* abort on warnings even inside an INSERT/UPDATE
trigger.
Tests for Stored Procedures, Stored Functions, Triggers involving SQL_MODE
have been included or revised, to reflect the intended behavior.
(reposting approved patch, to work around source control issues, no review needed)
When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION
or CREATE TRIGGER statements with a syntax error in it, the preparation
would fail with syntax error message, but the memory could be corrupted.
The problem occurred because we switch memroot when parse stored
routine or trigger definitions, and on parse error we restored the
original memroot only after performing some memory operations. In more
detail:
- prepared statement would activate its own memory root to parse
the definition of the stored procedure.
- SP would reset this memory root with its own memory root to
parse SP statements
- a syntax error would happen
- prepared statement would restore the original memory root
- stored procedure would restore what it thinks was the original
memory root, but actually was the statement memory root.
That led to double free - in destruction of the statement and in
a next call to mysql_parse().
The solution is to restore memroot right after the failed parsing.
(COUNT(*) = 1) not working in SELECT inside prepared statement.
Note: the warning was introduced in 5.0 and 5.1, 4.1 is OK with the
original fix.
The problem was that in 5.0 and 5.1 clear() for group functions may
access hybrid_type member, and this member is initialized in
fix_fields().
So we should not call clear() from item cleanup() methods, as cleanup()
may be called for unfixed items.
should fail to create
The problem was that this type of errors was checked during view
creation, which doesn't happen when CREATE VIEW is a statement of
a created stored routine.
The solution is to perform the checks at parse time. The idea of the
fix is that the parser checks if a construction just parsed is allowed
in current circumstances by testing certain flags, and this flags are
reset for VIEWs.
The side effect of this change is that if the user already have
such bogus routines, it will now get a error when trying to do
SHOW CREATE PROCEDURE proc;
(and some other) and when trying to execute such routine he will get
ERROR 1457 (HY000): Failed to load routine test.p5. The table mysql.proc is missing, corrupt, or contains bad data (internal code -6)
However there should be very few such users (if any), and they may
(and should) drop these bogus routines.
statement.
The problem was that during statement re-execution if the result was
empty the old result could be returned for group functions.
The solution is to implement proper cleanup() method in group
functions.
In a trigger or a function used in a statement it is possible to do
SELECT from a table being modified by the statement. However,
encapsulation of such SELECT into a view and selecting from a view
instead of direct SELECT was not possible.
This happened because tables used by views (which in their turn
were used from functions/triggers) were not excluded from checks
in unique_table() routine as it happens for the rest of tables
added to the statement table list for prelocking.
With this fix we ignore all such tables in unique_table(), thus
providing consistency: inside a trigger or a functions SELECT from
a view may be used where plain SELECT is allowed. Modification of
the same table from function or trigger is still disallowed. Also,
this patch doesn't affect the case where SELECT from the table being
modified is done outside of function of trigger, such SELECTs are
still disallowed (this limitation and visibility problem when function
select from a table being modified are subjects of bug 21326). See
also bug 22427.
The syntax of the CALL statement, to invoke a stored procedure, has been
changed to make the use of parenthesis optional in the argument list.
With this change, "CALL p;" is equivalent to "CALL p();".
While the SQL spec does not explicitely mandate this syntax, supporting it
is needed for practical reasons, for integration with JDBC / ODBC connectors.
Also, warnings in the sql/sql_yacc.yy file, which were not reported by Bison 2.1
but are now reported by Bison 2.2, have been fixed.
The warning found were:
bison -y -p MYSQL -d --debug --verbose sql_yacc.yy
sql_yacc.yy:653.9-18: warning: symbol UNLOCK_SYM redeclared
sql_yacc.yy:656.9-17: warning: symbol UNTIL_SYM redeclared
sql_yacc.yy:658.9-18: warning: symbol UPDATE_SYM redeclared
sql_yacc.yy:5169.11-5174.11: warning: unused value: $2
sql_yacc.yy:5208.11-5220.11: warning: unused value: $5
sql_yacc.yy:5221.11-5234.11: warning: unused value: $5
conflicts: 249 shift/reduce
"unused value: $2" correspond to the $$=$1 assignment in the 1st {} block
in table_ref -> join_table {} {},
which does not procude a result ($$) for the rule but an intermediate $2
value for the action instead.
"unused value: $5" are similar, with $$ assignments in {} actions blocks
which are not for the final reduce.
This is addition to fix for bug21617. Valgrind reports an error when
opening merge table that has underlying tables with less indexes than
in a merge table itself.
Copy at most min(file->keys, table->key_parts) elements from rec_per_key array.
This fixes problems when merge table and subtables have different number of keys.
Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored
procedures. However, 4.1 had some bugs that were fixed in 5.0 by the
patch for bug#21726, and this patch is a backport of those fixes.
Namely, in 4.1 it fixes:
- LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific).
- LAST_INSERT_ID() could return the value generated by current
statement if the call happens after the generation, like in
CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT);
INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID());
- Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
Though this is not storage engine specific problem, I was able to
repeat this problem with BDB and NDB engines only. That was the
reason to add a test case into ndb_update.test. As a result
different bad things could happen.
BDB has removed duplicate rows which is not expected.
NDB returns an error.
For multi table update notify storage engine about UPDATE IGNORE
as it is done in single table UPDATE.
The problem was a race condition in a test case.
The fix eliminates the race condition by explicit
wait on UNIX socket to start accepting connections.
The patch affects only test suite (i.e. does not touch
server codebase).
