2003-01-09 01:19:14 +01:00
|
|
|
/* Copyright (C) 2000-2003 MySQL AB
|
2000-08-21 13:35:27 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
2006-12-23 20:17:15 +01:00
|
|
|
the Free Software Foundation; version 2 of the License.
|
2000-08-21 13:35:27 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
2000-08-21 13:35:27 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program; if not, write to the Free Software
|
|
|
|
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */
|
|
|
|
|
2000-12-15 12:18:52 +01:00
|
|
|
/* sql_yacc.yy */
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
%{
|
2002-11-30 16:43:53 +01:00
|
|
|
/* thd is passed as an arg to yyparse(), and subsequently to yylex().
|
|
|
|
** The type will be void*, so it must be cast to (THD*) when used.
|
|
|
|
** Use the YYTHD macro for this.
|
2002-11-26 14:18:16 +01:00
|
|
|
*/
|
|
|
|
#define YYPARSE_PARAM yythd
|
2002-11-30 16:43:53 +01:00
|
|
|
#define YYLEX_PARAM yythd
|
2002-11-26 14:18:16 +01:00
|
|
|
#define YYTHD ((THD *)yythd)
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
#define MYSQL_YACC
|
|
|
|
#define YYINITDEPTH 100
|
|
|
|
#define YYMAXDEPTH 3200 /* Because of 64K stack */
|
2003-12-19 18:52:13 +01:00
|
|
|
#define Lex (YYTHD->lex)
|
2002-10-30 12:18:52 +01:00
|
|
|
#define Select Lex->current_select
|
2000-07-31 21:29:14 +02:00
|
|
|
#include "mysql_priv.h"
|
2001-10-09 14:53:54 +02:00
|
|
|
#include "slave.h"
|
2000-07-31 21:29:14 +02:00
|
|
|
#include "lex_symbol.h"
|
2002-10-02 12:33:08 +02:00
|
|
|
#include "item_create.h"
|
2004-11-12 04:01:46 +01:00
|
|
|
#include "sp_head.h"
|
|
|
|
#include "sp_pcontext.h"
|
|
|
|
#include "sp_rcontext.h"
|
|
|
|
#include "sp.h"
|
2006-06-27 08:48:50 +02:00
|
|
|
#include "event_data_objects.h"
|
2000-07-31 21:29:14 +02:00
|
|
|
#include <myisam.h>
|
2001-09-22 16:40:57 +02:00
|
|
|
#include <myisammrg.h>
|
2000-08-21 13:35:27 +02:00
|
|
|
|
2002-11-30 16:43:53 +01:00
|
|
|
int yylex(void *yylval, void *yythd);
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-01-16 13:16:23 +01:00
|
|
|
const LEX_STRING null_lex_str={0,0};
|
|
|
|
|
2005-07-18 14:33:18 +02:00
|
|
|
#define yyoverflow(A,B,C,D,E,F) {ulong val= *(F); if (my_yyoverflow((B), (D), &val)) { yyerror((char*) (A)); return 2; } else { *(F)= (YYSIZE_T)val; }}
|
2000-07-31 21:29:14 +02:00
|
|
|
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
#define MYSQL_YYABORT \
|
|
|
|
do \
|
2005-03-16 01:13:23 +01:00
|
|
|
{ \
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
LEX::cleanup_lex_after_parse_error(YYTHD);\
|
2005-03-16 01:13:23 +01:00
|
|
|
YYABORT; \
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
} while (0)
|
|
|
|
|
|
|
|
#define MYSQL_YYABORT_UNLESS(A) \
|
2005-04-04 00:50:05 +02:00
|
|
|
if (!(A)) \
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
{ \
|
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));\
|
|
|
|
MYSQL_YYABORT; \
|
2005-03-16 01:13:23 +01:00
|
|
|
}
|
|
|
|
|
Bug#21029 (Dependencies between sql_yacc.cc and dependent headers not detected)
The build scripts in general, using automake, autoconf, etc, contain several
special commands and work around all related to the way the bison code in the
parser is built, for sql/sql_yacc.yy. These work arounds, accumulated over
time during development, ultimately cause the build scripts to be unstable
and cause build defects by not enforcing dependencies.
This fix simplifies the build process and aligns it with the automake tooling,
which provides native support for bison and *.yy files.
In particular, the following problem have been fixed:
- dependencies with sql_yacc.cc were not honored (Bug 21029), leading to
corrupted builds,
- the work around introduced by Bug 24557, to cleanup the generated files
sql_yacc.h and sql_yacc.cc, has been removed,
- the generated makefile, in a source distribution, used to destroy the files
sql_yacc.h and sql_yacc.cc on a 'make clean' target. This has been fixed:
these files are now removed by make maintainer-clean.
- The root cause of the problem found with gcc 4.1 (see Bug 24619) has been
clearly documented, and the "sed" hack has been replaced by a cleaner
work around, when building the code with bison 1.875.
- Removed the file sql/sql_yacc.yy.bak, added by WL 3031 by accident.
- Removed the unnecessary AM_YFLAG= --debug introduced by WL 3432, since
the compiling option DBUG_OFF takes precedence when setting YYDEBUG.
2007-01-24 22:40:39 +01:00
|
|
|
/*
|
|
|
|
Work around for broken code generated by bison 1.875.
|
|
|
|
|
|
|
|
The code generated by bison 1.875a and later, bison 2.1 and bison 2.2 is ok.
|
|
|
|
With bison 1.875 however, the generated code contains:
|
|
|
|
<pre>
|
|
|
|
yyerrlab1:
|
|
|
|
#if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + __GNUC_MINOR__)
|
|
|
|
__attribute__ ((__unused__))
|
|
|
|
#endif
|
|
|
|
</pre>
|
|
|
|
This usage of __attribute__ is illegal, so we remove it.
|
|
|
|
See the following references for details:
|
|
|
|
http://lists.gnu.org/archive/html/bug-bison/2004-02/msg00014.html
|
|
|
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14273
|
|
|
|
*/
|
|
|
|
|
|
|
|
#if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + __GNUC_MINOR__)
|
|
|
|
#undef __attribute__
|
|
|
|
#define __attribute__(X)
|
|
|
|
#endif
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2006-08-19 04:16:07 +02:00
|
|
|
#ifndef DBUG_OFF
|
|
|
|
#define YYDEBUG 1
|
|
|
|
#else
|
|
|
|
#define YYDEBUG 0
|
|
|
|
#endif
|
|
|
|
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
/**
|
|
|
|
@brief Push an error message into MySQL error stack with line
|
|
|
|
and position information.
|
|
|
|
|
|
|
|
This function provides semantic action implementers with a way
|
|
|
|
to push the famous "You have a syntax error near..." error
|
|
|
|
message into the error stack, which is normally produced only if
|
|
|
|
a parse error is discovered internally by the Bison generated
|
|
|
|
parser.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void my_parse_error(const char *s)
|
|
|
|
{
|
|
|
|
THD *thd= current_thd;
|
2007-04-26 05:38:12 +02:00
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
const char *yytext= lip->get_tok_start();
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
/* Push an error into the error stack */
|
|
|
|
my_printf_error(ER_PARSE_ERROR, ER(ER_PARSE_ERROR), MYF(0), s,
|
2007-04-26 05:38:12 +02:00
|
|
|
(yytext ? yytext : ""),
|
|
|
|
lip->yylineno);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
@brief Bison callback to report a syntax/OOM error
|
|
|
|
|
|
|
|
This function is invoked by the bison-generated parser
|
|
|
|
when a syntax error, a parse error or an out-of-memory
|
|
|
|
condition occurs. This function is not invoked when the
|
|
|
|
parser is requested to abort by semantic action code
|
|
|
|
by means of YYABORT or YYACCEPT macros. This is why these
|
|
|
|
macros should not be used (use MYSQL_YYABORT/MYSQL_YYACCEPT
|
|
|
|
instead).
|
|
|
|
|
|
|
|
The parser will abort immediately after invoking this callback.
|
|
|
|
|
|
|
|
This function is not for use in semantic actions and is internal to
|
|
|
|
the parser, as it performs some pre-return cleanup.
|
|
|
|
In semantic actions, please use my_parse_error or my_error to
|
|
|
|
push an error into the error stack and MYSQL_YYABORT
|
|
|
|
to abort from the parser.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void MYSQLerror(const char *s)
|
|
|
|
{
|
|
|
|
THD *thd= current_thd;
|
|
|
|
|
|
|
|
/*
|
|
|
|
Restore the original LEX if it was replaced when parsing
|
|
|
|
a stored procedure. We must ensure that a parsing error
|
|
|
|
does not leave any side effects in the THD.
|
|
|
|
*/
|
|
|
|
LEX::cleanup_lex_after_parse_error(thd);
|
|
|
|
|
|
|
|
/* "parse error" changed into "syntax error" between bison 1.75 and 1.875 */
|
|
|
|
if (strcmp(s,"parse error") == 0 || strcmp(s,"syntax error") == 0)
|
|
|
|
s= ER(ER_SYNTAX_ERROR);
|
|
|
|
my_parse_error(s);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-08-19 04:16:07 +02:00
|
|
|
#ifndef DBUG_OFF
|
|
|
|
void turn_parser_debug_on()
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
MYSQLdebug is in sql/sql_yacc.cc, in bison generated code.
|
|
|
|
Turning this option on is **VERY** verbose, and should be
|
|
|
|
used when investigating a syntax error problem only.
|
|
|
|
|
|
|
|
The syntax to run with bison traces is as follows :
|
|
|
|
- Starting a server manually :
|
|
|
|
mysqld --debug="d,parser_debug" ...
|
|
|
|
- Running a test :
|
|
|
|
mysql-test-run.pl --mysqld="--debug=d,parser_debug" ...
|
|
|
|
|
|
|
|
The result will be in the process stderr (var/log/master.err)
|
|
|
|
*/
|
|
|
|
|
|
|
|
extern int yydebug;
|
|
|
|
yydebug= 1;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
Bug#18239 (Possible to overload internal functions with stored functions)
Bug#21025 (misleading error message when creating functions named 'x', or 'y')
Bug#22619 (Spaces considered harmful)
This change contains a fix to report warnings or errors, and multiple tests
cases.
Before this fix, name collisions between:
- Native functions
- User Defined Functions
- Stored Functions
were not systematically reported, leading to confusing behavior.
I) Native / User Defined Function
Before this fix, is was possible to create a UDF named "foo", with the same
name as a native function "foo", but it was impossible to invoke the UDF,
since the syntax "foo()" always refer to the native function.
After this fix, creating a UDF fails with an error if there is a name
collision with a native function.
II) Native / Stored Function
Before this fix, is was possible to create a SF named "db.foo", with the same
name as a native function "foo", but this was confusing since the syntax
"foo()" would refer to the native function. To refer to the Stored Function,
the user had to use the "db.foo()" syntax.
After this fix, creating a Stored Function reports a warning if there is a
name collision with a native function.
III) User Defined Function / Stored Function
Before this fix, creating a User Defined Function "foo" and a Stored Function
"db.foo" are mutually exclusive operations. Whenever the second function is
created, an error is reported. However, the test suite did not cover this
behavior.
After this fix, the behavior is unchanged, and is now covered by test cases.
Note that the code change in this patch depends on the fix for Bug 21114.
2006-11-15 03:34:16 +01:00
|
|
|
static bool is_native_function(THD *thd, const LEX_STRING *name)
|
|
|
|
{
|
|
|
|
if (find_native_function_builder(thd, *name))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (is_lex_native_function(name))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
Helper action for a case statement (entering the CASE).
|
|
|
|
This helper is used for both 'simple' and 'searched' cases.
|
2006-12-12 00:59:02 +01:00
|
|
|
This helper, with the other case_stmt_action_..., is executed when
|
|
|
|
the following SQL code is parsed:
|
|
|
|
<pre>
|
|
|
|
CREATE PROCEDURE proc_19194_simple(i int)
|
|
|
|
BEGIN
|
|
|
|
DECLARE str CHAR(10);
|
|
|
|
|
|
|
|
CASE i
|
|
|
|
WHEN 1 THEN SET str="1";
|
|
|
|
WHEN 2 THEN SET str="2";
|
|
|
|
WHEN 3 THEN SET str="3";
|
|
|
|
ELSE SET str="unknown";
|
|
|
|
END CASE;
|
|
|
|
|
|
|
|
SELECT str;
|
|
|
|
END
|
|
|
|
</pre>
|
|
|
|
The actions are used to generate the following code:
|
|
|
|
<pre>
|
|
|
|
SHOW PROCEDURE CODE proc_19194_simple;
|
|
|
|
Pos Instruction
|
|
|
|
0 set str@1 NULL
|
|
|
|
1 set_case_expr (12) 0 i@0
|
|
|
|
2 jump_if_not 5(12) (case_expr@0 = 1)
|
|
|
|
3 set str@1 _latin1'1'
|
|
|
|
4 jump 12
|
|
|
|
5 jump_if_not 8(12) (case_expr@0 = 2)
|
|
|
|
6 set str@1 _latin1'2'
|
|
|
|
7 jump 12
|
|
|
|
8 jump_if_not 11(12) (case_expr@0 = 3)
|
|
|
|
9 set str@1 _latin1'3'
|
|
|
|
10 jump 12
|
|
|
|
11 set str@1 _latin1'unknown'
|
|
|
|
12 stmt 0 "SELECT str"
|
|
|
|
</pre>
|
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
@param lex the parser lex context
|
|
|
|
*/
|
|
|
|
|
|
|
|
void case_stmt_action_case(LEX *lex)
|
|
|
|
{
|
|
|
|
lex->sphead->new_cont_backpatch(NULL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
BACKPATCH: Creating target label for the jump to
|
|
|
|
"case_stmt_action_end_case"
|
2006-12-12 00:59:02 +01:00
|
|
|
(Instruction 12 in the example)
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
lex->spcont->push_label((char *)"", lex->sphead->instructions());
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Helper action for a case expression statement (the expr in 'CASE expr').
|
|
|
|
This helper is used for 'searched' cases only.
|
|
|
|
@param lex the parser lex context
|
|
|
|
@param expr the parsed expression
|
|
|
|
@return 0 on success
|
|
|
|
*/
|
|
|
|
|
|
|
|
int case_stmt_action_expr(LEX *lex, Item* expr)
|
|
|
|
{
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
sp_pcontext *parsing_ctx= lex->spcont;
|
|
|
|
int case_expr_id= parsing_ctx->register_case_expr();
|
|
|
|
sp_instr_set_case_expr *i;
|
|
|
|
|
|
|
|
if (parsing_ctx->push_case_expr_id(case_expr_id))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
i= new sp_instr_set_case_expr(sp->instructions(),
|
|
|
|
parsing_ctx, case_expr_id, expr, lex);
|
|
|
|
|
|
|
|
sp->add_cont_backpatch(i);
|
|
|
|
sp->add_instr(i);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Helper action for a case when condition.
|
|
|
|
This helper is used for both 'simple' and 'searched' cases.
|
|
|
|
@param lex the parser lex context
|
|
|
|
@param when the parsed expression for the WHEN clause
|
|
|
|
@param simple true for simple cases, false for searched cases
|
|
|
|
*/
|
|
|
|
|
|
|
|
void case_stmt_action_when(LEX *lex, Item *when, bool simple)
|
|
|
|
{
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
sp_pcontext *ctx= lex->spcont;
|
|
|
|
uint ip= sp->instructions();
|
|
|
|
sp_instr_jump_if_not *i;
|
|
|
|
Item_case_expr *var;
|
|
|
|
Item *expr;
|
|
|
|
|
|
|
|
if (simple)
|
|
|
|
{
|
|
|
|
var= new Item_case_expr(ctx->get_current_case_expr_id());
|
|
|
|
|
|
|
|
#ifndef DBUG_OFF
|
|
|
|
if (var)
|
|
|
|
{
|
|
|
|
var->m_sp= sp;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
expr= new Item_func_eq(var, when);
|
|
|
|
i= new sp_instr_jump_if_not(ip, ctx, expr, lex);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
i= new sp_instr_jump_if_not(ip, ctx, when, lex);
|
|
|
|
|
|
|
|
/*
|
|
|
|
BACKPATCH: Registering forward jump from
|
|
|
|
"case_stmt_action_when" to "case_stmt_action_then"
|
2006-12-12 00:59:02 +01:00
|
|
|
(jump_if_not from instruction 2 to 5, 5 to 8 ... in the example)
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
sp->push_backpatch(i, ctx->push_label((char *)"", 0));
|
|
|
|
sp->add_cont_backpatch(i);
|
|
|
|
sp->add_instr(i);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Helper action for a case then statements.
|
|
|
|
This helper is used for both 'simple' and 'searched' cases.
|
|
|
|
@param lex the parser lex context
|
|
|
|
*/
|
|
|
|
|
|
|
|
void case_stmt_action_then(LEX *lex)
|
|
|
|
{
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
sp_pcontext *ctx= lex->spcont;
|
|
|
|
uint ip= sp->instructions();
|
|
|
|
sp_instr_jump *i = new sp_instr_jump(ip, ctx);
|
|
|
|
sp->add_instr(i);
|
|
|
|
|
|
|
|
/*
|
|
|
|
BACKPATCH: Resolving forward jump from
|
|
|
|
"case_stmt_action_when" to "case_stmt_action_then"
|
2006-12-12 00:59:02 +01:00
|
|
|
(jump_if_not from instruction 2 to 5, 5 to 8 ... in the example)
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
sp->backpatch(ctx->pop_label());
|
|
|
|
|
|
|
|
/*
|
|
|
|
BACKPATCH: Registering forward jump from
|
2006-12-12 00:59:02 +01:00
|
|
|
"case_stmt_action_then" to "case_stmt_action_end_case"
|
|
|
|
(jump from instruction 4 to 12, 7 to 12 ... in the example)
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
sp->push_backpatch(i, ctx->last_label());
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Helper action for an end case.
|
|
|
|
This helper is used for both 'simple' and 'searched' cases.
|
|
|
|
@param lex the parser lex context
|
|
|
|
@param simple true for simple cases, false for searched cases
|
|
|
|
*/
|
|
|
|
|
|
|
|
void case_stmt_action_end_case(LEX *lex, bool simple)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
BACKPATCH: Resolving forward jump from
|
|
|
|
"case_stmt_action_then" to "case_stmt_action_end_case"
|
2006-12-12 00:59:02 +01:00
|
|
|
(jump from instruction 4 to 12, 7 to 12 ... in the example)
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
*/
|
|
|
|
lex->sphead->backpatch(lex->spcont->pop_label());
|
|
|
|
|
|
|
|
if (simple)
|
|
|
|
lex->spcont->pop_case_expr_id();
|
|
|
|
|
|
|
|
lex->sphead->do_cont_backpatch();
|
|
|
|
}
|
|
|
|
|
2007-01-30 01:32:52 +01:00
|
|
|
/**
|
|
|
|
Helper to resolve the SQL:2003 Syntax exception 1) in <in predicate>.
|
|
|
|
See SQL:2003, Part 2, section 8.4 <in predicate>, Note 184, page 383.
|
|
|
|
This function returns the proper item for the SQL expression
|
|
|
|
<code>left [NOT] IN ( expr )</code>
|
|
|
|
@param thd the current thread
|
|
|
|
@param left the in predicand
|
|
|
|
@param equal true for IN predicates, false for NOT IN predicates
|
|
|
|
@param expr first and only expression of the in value list
|
|
|
|
@return an expression representing the IN predicate.
|
|
|
|
*/
|
|
|
|
Item* handle_sql2003_note184_exception(THD *thd, Item* left, bool equal,
|
|
|
|
Item *expr)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
Relevant references for this issue:
|
|
|
|
- SQL:2003, Part 2, section 8.4 <in predicate>, page 383,
|
|
|
|
- SQL:2003, Part 2, section 7.2 <row value expression>, page 296,
|
|
|
|
- SQL:2003, Part 2, section 6.3 <value expression primary>, page 174,
|
|
|
|
- SQL:2003, Part 2, section 7.15 <subquery>, page 370,
|
|
|
|
- SQL:2003 Feature F561, "Full value expressions".
|
|
|
|
|
|
|
|
The exception in SQL:2003 Note 184 means:
|
|
|
|
Item_singlerow_subselect, which corresponds to a <scalar subquery>,
|
|
|
|
should be re-interpreted as an Item_in_subselect, which corresponds
|
|
|
|
to a <table subquery> when used inside an <in predicate>.
|
|
|
|
|
|
|
|
Our reading of Note 184 is reccursive, so that all:
|
|
|
|
- IN (( <subquery> ))
|
|
|
|
- IN ((( <subquery> )))
|
|
|
|
- IN '('^N <subquery> ')'^N
|
|
|
|
- etc
|
|
|
|
should be interpreted as a <table subquery>, no matter how deep in the
|
|
|
|
expression the <subquery> is.
|
|
|
|
*/
|
|
|
|
|
|
|
|
Item *result;
|
|
|
|
|
|
|
|
DBUG_ENTER("handle_sql2003_note184_exception");
|
|
|
|
|
|
|
|
if (expr->type() == Item::SUBSELECT_ITEM)
|
|
|
|
{
|
|
|
|
Item_subselect *expr2 = (Item_subselect*) expr;
|
|
|
|
|
|
|
|
if (expr2->substype() == Item_subselect::SINGLEROW_SUBS)
|
|
|
|
{
|
|
|
|
Item_singlerow_subselect *expr3 = (Item_singlerow_subselect*) expr2;
|
|
|
|
st_select_lex *subselect;
|
|
|
|
|
|
|
|
/*
|
|
|
|
Implement the mandated change, by altering the semantic tree:
|
|
|
|
left IN Item_singlerow_subselect(subselect)
|
|
|
|
is modified to
|
|
|
|
left IN (subselect)
|
|
|
|
which is represented as
|
|
|
|
Item_in_subselect(left, subselect)
|
|
|
|
*/
|
|
|
|
subselect= expr3->invalidate_and_restore_select_lex();
|
|
|
|
result= new (thd->mem_root) Item_in_subselect(left, subselect);
|
|
|
|
|
|
|
|
if (! equal)
|
|
|
|
result = negate_expression(thd, result);
|
|
|
|
|
|
|
|
DBUG_RETURN(result);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (equal)
|
|
|
|
result= new (thd->mem_root) Item_func_eq(left, expr);
|
|
|
|
else
|
|
|
|
result= new (thd->mem_root) Item_func_ne(left, expr);
|
|
|
|
|
|
|
|
DBUG_RETURN(result);
|
|
|
|
}
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
%}
|
|
|
|
%union {
|
|
|
|
int num;
|
|
|
|
ulong ulong_num;
|
2001-09-14 01:54:33 +02:00
|
|
|
ulonglong ulonglong_number;
|
2005-07-22 20:47:05 +02:00
|
|
|
longlong longlong_number;
|
2000-07-31 21:29:14 +02:00
|
|
|
LEX_STRING lex_str;
|
|
|
|
LEX_STRING *lex_str_ptr;
|
|
|
|
LEX_SYMBOL symbol;
|
|
|
|
Table_ident *table;
|
|
|
|
char *simple_string;
|
|
|
|
Item *item;
|
2004-03-18 17:27:03 +01:00
|
|
|
Item_num *item_num;
|
2000-07-31 21:29:14 +02:00
|
|
|
List<Item> *item_list;
|
|
|
|
List<String> *string_list;
|
2002-07-23 17:31:22 +02:00
|
|
|
String *string;
|
2007-06-10 12:43:57 +02:00
|
|
|
Key_part_spec *key_part;
|
2002-07-23 17:31:22 +02:00
|
|
|
TABLE_LIST *table_list;
|
|
|
|
udf_func *udf;
|
|
|
|
LEX_USER *lex_user;
|
2003-08-18 23:08:08 +02:00
|
|
|
struct sys_var_with_base variable;
|
2005-08-27 15:51:11 +02:00
|
|
|
enum enum_var_type var_type;
|
2000-07-31 21:29:14 +02:00
|
|
|
Key::Keytype key_type;
|
2003-08-18 23:08:08 +02:00
|
|
|
enum ha_key_alg key_alg;
|
2005-12-21 19:18:40 +01:00
|
|
|
handlerton *db_type;
|
2000-07-31 21:29:14 +02:00
|
|
|
enum row_type row_type;
|
2001-11-05 23:05:45 +01:00
|
|
|
enum ha_rkey_function ha_rkey_mode;
|
2001-03-21 00:02:22 +01:00
|
|
|
enum enum_tx_isolation tx_isolation;
|
2003-07-06 17:12:45 +02:00
|
|
|
enum Cast_target cast_type;
|
2000-07-31 21:29:14 +02:00
|
|
|
enum Item_udftype udf_type;
|
2002-09-12 16:36:22 +02:00
|
|
|
CHARSET_INFO *charset;
|
2002-11-16 19:19:10 +01:00
|
|
|
thr_lock_type lock_type;
|
2004-11-12 04:01:46 +01:00
|
|
|
interval_type interval, interval_time_st;
|
2003-11-03 13:01:59 +01:00
|
|
|
timestamp_type date_time_type;
|
2002-10-27 22:27:00 +01:00
|
|
|
st_select_lex *select_lex;
|
2002-11-07 22:45:19 +01:00
|
|
|
chooser_compare_func_creator boolfunc2creator;
|
2004-11-12 04:01:46 +01:00
|
|
|
struct sp_cond_type *spcondtype;
|
|
|
|
struct { int vars, conds, hndlrs, curs; } spblock;
|
|
|
|
sp_name *spname;
|
|
|
|
struct st_lex *lex;
|
2005-12-15 14:12:28 +01:00
|
|
|
sp_head *sphead;
|
2006-03-07 12:25:08 +01:00
|
|
|
struct p_elem_val *p_elem_value;
|
2007-03-05 18:08:41 +01:00
|
|
|
enum index_hint_type index_hint;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
%{
|
2004-06-24 01:57:57 +02:00
|
|
|
bool my_yyoverflow(short **a, YYSTYPE **b, ulong *yystacksize);
|
2000-07-31 21:29:14 +02:00
|
|
|
%}
|
|
|
|
|
|
|
|
%pure_parser /* We have threads */
|
2007-03-02 13:05:16 +01:00
|
|
|
/*
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
Currently there is 286 shift/reduce conflict. We should not introduce
|
2007-03-02 13:05:16 +01:00
|
|
|
new conflicts any more.
|
|
|
|
*/
|
2007-03-09 13:52:50 +01:00
|
|
|
%expect 286
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2006-11-02 19:01:53 +01:00
|
|
|
/*
|
|
|
|
Comments for TOKENS.
|
|
|
|
For each token, please include in the same line a comment that contains
|
|
|
|
the following tags:
|
|
|
|
SQL-2003-R : Reserved keyword as per SQL-2003
|
|
|
|
SQL-2003-N : Non Reserved keyword as per SQL-2003
|
|
|
|
SQL-1999-R : Reserved keyword as per SQL-1999
|
|
|
|
SQL-1999-N : Non Reserved keyword as per SQL-1999
|
|
|
|
MYSQL : MySQL extention (unspecified)
|
|
|
|
MYSQL-FUNC : MySQL extention, function
|
|
|
|
INTERNAL : Not a real token, lex optimization
|
|
|
|
OPERATOR : SQL operator
|
|
|
|
FUTURE-USE : Reserved for futur use
|
|
|
|
|
|
|
|
This makes the code grep-able, and helps maintenance.
|
|
|
|
*/
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2006-11-02 19:01:53 +01:00
|
|
|
%token ABORT_SYM /* INTERNAL (used in lex) */
|
2006-01-11 11:35:25 +01:00
|
|
|
%token ACCESSIBLE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token ACTION /* SQL-2003-N */
|
|
|
|
%token ADD /* SQL-2003-R */
|
|
|
|
%token ADDDATE_SYM /* MYSQL-FUNC */
|
|
|
|
%token AFTER_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token AGAINST
|
|
|
|
%token AGGREGATE_SYM
|
|
|
|
%token ALGORITHM_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token ALL /* SQL-2003-R */
|
|
|
|
%token ALTER /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token ANALYZE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token AND_AND_SYM /* OPERATOR */
|
|
|
|
%token AND_SYM /* SQL-2003-R */
|
|
|
|
%token ANY_SYM /* SQL-2003-R */
|
|
|
|
%token AS /* SQL-2003-R */
|
|
|
|
%token ASC /* SQL-2003-N */
|
|
|
|
%token ASCII_SYM /* MYSQL-FUNC */
|
|
|
|
%token ASENSITIVE_SYM /* FUTURE-USE */
|
|
|
|
%token AT_SYM /* SQL-2003-R */
|
2005-11-10 18:43:17 +01:00
|
|
|
%token AUTHORS_SYM
|
2006-01-11 11:35:25 +01:00
|
|
|
%token AUTOEXTEND_SIZE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token AUTO_INC
|
2005-01-16 13:16:23 +01:00
|
|
|
%token AVG_ROW_LENGTH
|
2006-11-02 19:01:53 +01:00
|
|
|
%token AVG_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token BACKUP_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token BEFORE_SYM /* SQL-2003-N */
|
|
|
|
%token BEGIN_SYM /* SQL-2003-R */
|
|
|
|
%token BETWEEN_SYM /* SQL-2003-R */
|
|
|
|
%token BIGINT /* SQL-2003-R */
|
|
|
|
%token BINARY /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token BINLOG_SYM
|
2004-12-17 15:06:05 +01:00
|
|
|
%token BIN_NUM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token BIT_AND /* MYSQL-FUNC */
|
|
|
|
%token BIT_OR /* MYSQL-FUNC */
|
|
|
|
%token BIT_SYM /* MYSQL-FUNC */
|
|
|
|
%token BIT_XOR /* MYSQL-FUNC */
|
|
|
|
%token BLOB_SYM /* SQL-2003-R */
|
|
|
|
%token BOOLEAN_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token BOOL_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token BOTH /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token BTREE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token BY /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token BYTE_SYM
|
|
|
|
%token CACHE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token CALL_SYM /* SQL-2003-R */
|
|
|
|
%token CASCADE /* SQL-2003-N */
|
|
|
|
%token CASCADED /* SQL-2003-R */
|
|
|
|
%token CASE_SYM /* SQL-2003-R */
|
|
|
|
%token CAST_SYM /* SQL-2003-R */
|
|
|
|
%token CHAIN_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token CHANGE
|
|
|
|
%token CHANGED
|
|
|
|
%token CHARSET
|
2006-11-02 19:01:53 +01:00
|
|
|
%token CHAR_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token CHECKSUM_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token CHECK_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token CIPHER_SYM
|
|
|
|
%token CLIENT_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token CLOSE_SYM /* SQL-2003-R */
|
|
|
|
%token COALESCE /* SQL-2003-N */
|
2005-11-17 11:11:48 +01:00
|
|
|
%token CODE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token COLLATE_SYM /* SQL-2003-R */
|
|
|
|
%token COLLATION_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token COLUMNS
|
2006-11-02 19:01:53 +01:00
|
|
|
%token COLUMN_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token COMMENT_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token COMMITTED_SYM /* SQL-2003-N */
|
|
|
|
%token COMMIT_SYM /* SQL-2003-R */
|
2005-02-14 21:50:09 +01:00
|
|
|
%token COMPACT_SYM
|
2005-12-02 13:07:02 +01:00
|
|
|
%token COMPLETION_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token COMPRESSED_SYM
|
|
|
|
%token CONCURRENT
|
2006-11-02 19:01:53 +01:00
|
|
|
%token CONDITION_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token CONNECTION_SYM
|
|
|
|
%token CONSISTENT_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token CONSTRAINT /* SQL-2003-R */
|
|
|
|
%token CONTAINS_SYM /* SQL-2003-N */
|
|
|
|
%token CONTINUE_SYM /* SQL-2003-R */
|
2006-05-03 02:53:26 +02:00
|
|
|
%token CONTRIBUTORS_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token CONVERT_SYM /* SQL-2003-N */
|
|
|
|
%token COUNT_SYM /* SQL-2003-N */
|
|
|
|
%token CREATE /* SQL-2003-R */
|
|
|
|
%token CROSS /* SQL-2003-R */
|
|
|
|
%token CUBE_SYM /* SQL-2003-R */
|
|
|
|
%token CURDATE /* MYSQL-FUNC */
|
|
|
|
%token CURRENT_USER /* SQL-2003-R */
|
|
|
|
%token CURSOR_SYM /* SQL-2003-R */
|
|
|
|
%token CURTIME /* MYSQL-FUNC */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token DATABASE
|
|
|
|
%token DATABASES
|
2006-01-11 11:35:25 +01:00
|
|
|
%token DATAFILE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token DATA_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token DATETIME
|
2006-11-02 19:01:53 +01:00
|
|
|
%token DATE_ADD_INTERVAL /* MYSQL-FUNC */
|
|
|
|
%token DATE_SUB_INTERVAL /* MYSQL-FUNC */
|
|
|
|
%token DATE_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token DAY_HOUR_SYM
|
|
|
|
%token DAY_MICROSECOND_SYM
|
|
|
|
%token DAY_MINUTE_SYM
|
|
|
|
%token DAY_SECOND_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token DAY_SYM /* SQL-2003-R */
|
|
|
|
%token DEALLOCATE_SYM /* SQL-2003-R */
|
2005-02-14 21:50:09 +01:00
|
|
|
%token DECIMAL_NUM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token DECIMAL_SYM /* SQL-2003-R */
|
|
|
|
%token DECLARE_SYM /* SQL-2003-R */
|
|
|
|
%token DEFAULT /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token DEFINER_SYM
|
|
|
|
%token DELAYED_SYM
|
|
|
|
%token DELAY_KEY_WRITE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token DELETE_SYM /* SQL-2003-R */
|
|
|
|
%token DESC /* SQL-2003-N */
|
|
|
|
%token DESCRIBE /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token DES_KEY_FILE
|
2006-11-02 19:01:53 +01:00
|
|
|
%token DETERMINISTIC_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token DIRECTORY_SYM
|
|
|
|
%token DISABLE_SYM
|
|
|
|
%token DISCARD
|
2006-01-11 11:35:25 +01:00
|
|
|
%token DISK_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token DISTINCT /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token DIV_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token DOUBLE_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token DO_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token DROP /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token DUAL_SYM
|
|
|
|
%token DUMPFILE
|
2003-01-21 20:07:59 +01:00
|
|
|
%token DUPLICATE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token DYNAMIC_SYM /* SQL-2003-R */
|
|
|
|
%token EACH_SYM /* SQL-2003-R */
|
|
|
|
%token ELSE /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token ELSEIF_SYM
|
|
|
|
%token ENABLE_SYM
|
|
|
|
%token ENCLOSED
|
2006-11-02 19:01:53 +01:00
|
|
|
%token END /* SQL-2003-R */
|
2005-12-02 13:07:02 +01:00
|
|
|
%token ENDS_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token END_OF_INPUT /* INTERNAL */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token ENGINES_SYM
|
|
|
|
%token ENGINE_SYM
|
|
|
|
%token ENUM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token EQ /* OPERATOR */
|
|
|
|
%token EQUAL_SYM /* OPERATOR */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token ERRORS
|
|
|
|
%token ESCAPED
|
2006-11-02 19:01:53 +01:00
|
|
|
%token ESCAPE_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token EVENTS_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token EVENT_SYM
|
|
|
|
%token EVERY_SYM /* SQL-2003-N */
|
|
|
|
%token EXECUTE_SYM /* SQL-2003-R */
|
|
|
|
%token EXISTS /* SQL-2003-R */
|
2004-11-12 04:01:46 +01:00
|
|
|
%token EXIT_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token EXPANSION_SYM
|
|
|
|
%token EXTENDED_SYM
|
2006-01-11 11:35:25 +01:00
|
|
|
%token EXTENT_SIZE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token EXTRACT_SYM /* SQL-2003-N */
|
|
|
|
%token FALSE_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token FAST_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token FETCH_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token FILE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token FIRST_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token FIXED_SYM
|
|
|
|
%token FLOAT_NUM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token FLOAT_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token FLUSH_SYM
|
|
|
|
%token FORCE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token FOREIGN /* SQL-2003-R */
|
|
|
|
%token FOR_SYM /* SQL-2003-R */
|
|
|
|
%token FOUND_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token FRAC_SECOND_SYM
|
|
|
|
%token FROM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token FULL /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token FULLTEXT_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token FUNCTION_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token GE
|
|
|
|
%token GEOMETRYCOLLECTION
|
|
|
|
%token GEOMETRY_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token GET_FORMAT /* MYSQL-FUNC */
|
|
|
|
%token GLOBAL_SYM /* SQL-2003-R */
|
|
|
|
%token GRANT /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token GRANTS
|
2007-02-23 21:48:15 +01:00
|
|
|
%token GROUP_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token GROUP_CONCAT_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token GT_SYM /* OPERATOR */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token HANDLER_SYM
|
|
|
|
%token HASH_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token HAVING /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token HELP_SYM
|
|
|
|
%token HEX_NUM
|
|
|
|
%token HIGH_PRIORITY
|
2006-12-02 01:47:45 +01:00
|
|
|
%token HOST_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token HOSTS_SYM
|
|
|
|
%token HOUR_MICROSECOND_SYM
|
|
|
|
%token HOUR_MINUTE_SYM
|
|
|
|
%token HOUR_SECOND_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token HOUR_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token IDENT
|
|
|
|
%token IDENTIFIED_SYM
|
|
|
|
%token IDENT_QUOTED
|
|
|
|
%token IF
|
|
|
|
%token IGNORE_SYM
|
|
|
|
%token IMPORT
|
|
|
|
%token INDEXES
|
|
|
|
%token INDEX_SYM
|
|
|
|
%token INFILE
|
2006-01-11 11:35:25 +01:00
|
|
|
%token INITIAL_SIZE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token INNER_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token INNOBASE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token INOUT_SYM /* SQL-2003-R */
|
|
|
|
%token INSENSITIVE_SYM /* SQL-2003-R */
|
|
|
|
%token INSERT /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token INSERT_METHOD
|
2005-11-06 13:13:06 +01:00
|
|
|
%token INSTALL_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token INTERVAL_SYM /* SQL-2003-R */
|
|
|
|
%token INTO /* SQL-2003-R */
|
|
|
|
%token INT_SYM /* SQL-2003-R */
|
2004-11-12 04:01:46 +01:00
|
|
|
%token INVOKER_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token IN_SYM /* SQL-2003-R */
|
|
|
|
%token IS /* SQL-2003-R */
|
|
|
|
%token ISOLATION /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token ISSUER_SYM
|
|
|
|
%token ITERATE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token JOIN_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token KEYS
|
2006-05-03 14:59:17 +02:00
|
|
|
%token KEY_BLOCK_SIZE
|
2006-11-02 19:01:53 +01:00
|
|
|
%token KEY_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token KILL_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token LANGUAGE_SYM /* SQL-2003-R */
|
|
|
|
%token LAST_SYM /* SQL-2003-N */
|
|
|
|
%token LE /* OPERATOR */
|
|
|
|
%token LEADING /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token LEAVES
|
|
|
|
%token LEAVE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token LEFT /* SQL-2003-R */
|
2005-07-18 13:31:02 +02:00
|
|
|
%token LESS_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token LEVEL_SYM
|
|
|
|
%token LEX_HOSTNAME
|
2006-11-02 19:01:53 +01:00
|
|
|
%token LIKE /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token LIMIT
|
2005-07-18 13:31:02 +02:00
|
|
|
%token LINEAR_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token LINES
|
|
|
|
%token LINESTRING
|
2005-07-18 13:31:02 +02:00
|
|
|
%token LIST_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token LOAD
|
2006-11-02 19:01:53 +01:00
|
|
|
%token LOCAL_SYM /* SQL-2003-R */
|
|
|
|
%token LOCATOR_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token LOCKS_SYM
|
|
|
|
%token LOCK_SYM
|
2006-01-11 11:35:25 +01:00
|
|
|
%token LOGFILE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token LOGS_SYM
|
|
|
|
%token LONGBLOB
|
|
|
|
%token LONGTEXT
|
|
|
|
%token LONG_NUM
|
|
|
|
%token LONG_SYM
|
|
|
|
%token LOOP_SYM
|
|
|
|
%token LOW_PRIORITY
|
2006-11-02 19:01:53 +01:00
|
|
|
%token LT /* OPERATOR */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token MASTER_CONNECT_RETRY_SYM
|
|
|
|
%token MASTER_HOST_SYM
|
|
|
|
%token MASTER_LOG_FILE_SYM
|
|
|
|
%token MASTER_LOG_POS_SYM
|
|
|
|
%token MASTER_PASSWORD_SYM
|
|
|
|
%token MASTER_PORT_SYM
|
|
|
|
%token MASTER_SERVER_ID_SYM
|
|
|
|
%token MASTER_SSL_CAPATH_SYM
|
|
|
|
%token MASTER_SSL_CA_SYM
|
|
|
|
%token MASTER_SSL_CERT_SYM
|
|
|
|
%token MASTER_SSL_CIPHER_SYM
|
|
|
|
%token MASTER_SSL_KEY_SYM
|
|
|
|
%token MASTER_SSL_SYM
|
2007-03-29 15:09:57 +02:00
|
|
|
%token MASTER_SSL_VERIFY_SERVER_CERT_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token MASTER_SYM
|
|
|
|
%token MASTER_USER_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token MATCH /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token MAX_CONNECTIONS_PER_HOUR
|
|
|
|
%token MAX_QUERIES_PER_HOUR
|
|
|
|
%token MAX_ROWS
|
2006-01-11 11:35:25 +01:00
|
|
|
%token MAX_SIZE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token MAX_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token MAX_UPDATES_PER_HOUR
|
2005-02-14 21:50:09 +01:00
|
|
|
%token MAX_USER_CONNECTIONS_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token MAX_VALUE_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token MEDIUMBLOB
|
|
|
|
%token MEDIUMINT
|
|
|
|
%token MEDIUMTEXT
|
|
|
|
%token MEDIUM_SYM
|
2006-01-11 11:35:25 +01:00
|
|
|
%token MEMORY_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token MERGE_SYM /* SQL-2003-R */
|
|
|
|
%token MICROSECOND_SYM /* MYSQL-FUNC */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token MIGRATE_SYM
|
|
|
|
%token MINUTE_MICROSECOND_SYM
|
|
|
|
%token MINUTE_SECOND_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token MINUTE_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token MIN_ROWS
|
2006-11-02 19:01:53 +01:00
|
|
|
%token MIN_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token MODE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token MODIFIES_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token MODIFY_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token MOD_SYM /* SQL-2003-N */
|
|
|
|
%token MONTH_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token MULTILINESTRING
|
|
|
|
%token MULTIPOINT
|
|
|
|
%token MULTIPOLYGON
|
2004-12-24 13:31:21 +01:00
|
|
|
%token MUTEX_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token NAMES_SYM /* SQL-2003-N */
|
|
|
|
%token NAME_SYM /* SQL-2003-N */
|
|
|
|
%token NATIONAL_SYM /* SQL-2003-R */
|
|
|
|
%token NATURAL /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token NCHAR_STRING
|
2006-11-02 19:01:53 +01:00
|
|
|
%token NCHAR_SYM /* SQL-2003-R */
|
2004-04-15 09:14:14 +02:00
|
|
|
%token NDBCLUSTER_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token NE /* OPERATOR */
|
|
|
|
%token NEG
|
|
|
|
%token NEW_SYM /* SQL-2003-R */
|
|
|
|
%token NEXT_SYM /* SQL-2003-N */
|
2005-07-18 13:31:02 +02:00
|
|
|
%token NODEGROUP_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token NONE_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token NOT2_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token NOT_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token NOW_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token NO_SYM /* SQL-2003-R */
|
2006-01-11 11:35:25 +01:00
|
|
|
%token NO_WAIT_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token NO_WRITE_TO_BINLOG
|
2006-11-02 19:01:53 +01:00
|
|
|
%token NULL_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token NUM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token NUMERIC_SYM /* SQL-2003-R */
|
2003-09-15 07:26:48 +02:00
|
|
|
%token NVARCHAR_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token OFFSET_SYM
|
|
|
|
%token OLD_PASSWORD
|
2006-11-02 19:01:53 +01:00
|
|
|
%token ON /* SQL-2003-R */
|
2004-06-03 23:17:18 +02:00
|
|
|
%token ONE_SHOT_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token ONE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token OPEN_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token OPTIMIZE
|
2006-12-02 01:47:45 +01:00
|
|
|
%token OPTIONS_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token OPTION /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token OPTIONALLY
|
|
|
|
%token OR2_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token ORDER_SYM /* SQL-2003-R */
|
|
|
|
%token OR_OR_SYM /* OPERATOR */
|
|
|
|
%token OR_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token OUTER
|
|
|
|
%token OUTFILE
|
2006-11-02 19:01:53 +01:00
|
|
|
%token OUT_SYM /* SQL-2003-R */
|
2006-12-02 01:47:45 +01:00
|
|
|
%token OWNER_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token PACK_KEYS_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token PARAM_MARKER
|
2005-11-06 13:13:06 +01:00
|
|
|
%token PARSER_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token PARTIAL /* SQL-2003-N */
|
2006-03-20 20:36:21 +01:00
|
|
|
%token PARTITIONING_SYM
|
2005-07-18 13:31:02 +02:00
|
|
|
%token PARTITIONS_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token PARTITION_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token PASSWORD
|
|
|
|
%token PHASE_SYM
|
2006-04-06 15:29:39 +02:00
|
|
|
%token PLUGINS_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token PLUGIN_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token POINT_SYM
|
|
|
|
%token POLYGON
|
2006-12-02 01:47:45 +01:00
|
|
|
%token PORT_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token POSITION_SYM /* SQL-2003-N */
|
|
|
|
%token PRECISION /* SQL-2003-R */
|
|
|
|
%token PREPARE_SYM /* SQL-2003-R */
|
2005-12-02 13:07:02 +01:00
|
|
|
%token PRESERVE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token PREV_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token PRIMARY_SYM /* SQL-2003-R */
|
|
|
|
%token PRIVILEGES /* SQL-2003-N */
|
|
|
|
%token PROCEDURE /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token PROCESS
|
|
|
|
%token PROCESSLIST_SYM
|
|
|
|
%token PURGE
|
|
|
|
%token QUARTER_SYM
|
|
|
|
%token QUERY_SYM
|
|
|
|
%token QUICK
|
2006-11-02 19:01:53 +01:00
|
|
|
%token RANGE_SYM /* SQL-2003-R */
|
|
|
|
%token READS_SYM /* SQL-2003-R */
|
2006-01-11 11:35:25 +01:00
|
|
|
%token READ_ONLY_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token READ_SYM /* SQL-2003-N */
|
2006-01-11 11:35:25 +01:00
|
|
|
%token READ_WRITE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token REAL /* SQL-2003-R */
|
2006-01-17 08:40:00 +01:00
|
|
|
%token REBUILD_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token RECOVER_SYM
|
2006-01-11 11:35:25 +01:00
|
|
|
%token REDOFILE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token REDO_BUFFER_SIZE_SYM
|
2005-02-14 21:50:09 +01:00
|
|
|
%token REDUNDANT_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token REFERENCES /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token REGEXP
|
|
|
|
%token RELAY_LOG_FILE_SYM
|
|
|
|
%token RELAY_LOG_POS_SYM
|
|
|
|
%token RELAY_THREAD
|
2006-11-02 19:01:53 +01:00
|
|
|
%token RELEASE_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token RELOAD
|
2006-03-20 20:36:21 +01:00
|
|
|
%token REMOVE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token RENAME
|
2006-01-17 08:40:00 +01:00
|
|
|
%token REORGANIZE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token REPAIR
|
2006-11-02 19:01:53 +01:00
|
|
|
%token REPEATABLE_SYM /* SQL-2003-N */
|
|
|
|
%token REPEAT_SYM /* MYSQL-FUNC */
|
|
|
|
%token REPLACE /* MYSQL-FUNC */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token REPLICATION
|
|
|
|
%token REQUIRE_SYM
|
|
|
|
%token RESET_SYM
|
|
|
|
%token RESOURCES
|
|
|
|
%token RESTORE_SYM
|
|
|
|
%token RESTRICT
|
|
|
|
%token RESUME_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token RETURNS_SYM /* SQL-2003-R */
|
|
|
|
%token RETURN_SYM /* SQL-2003-R */
|
|
|
|
%token REVOKE /* SQL-2003-R */
|
|
|
|
%token RIGHT /* SQL-2003-R */
|
|
|
|
%token ROLLBACK_SYM /* SQL-2003-R */
|
|
|
|
%token ROLLUP_SYM /* SQL-2003-R */
|
|
|
|
%token ROUTINE_SYM /* SQL-2003-N */
|
|
|
|
%token ROWS_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token ROW_FORMAT_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token ROW_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token RTREE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token SAVEPOINT_SYM /* SQL-2003-R */
|
2005-12-02 13:07:02 +01:00
|
|
|
%token SCHEDULE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token SECOND_MICROSECOND_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token SECOND_SYM /* SQL-2003-R */
|
|
|
|
%token SECURITY_SYM /* SQL-2003-N */
|
|
|
|
%token SELECT_SYM /* SQL-2003-R */
|
|
|
|
%token SENSITIVE_SYM /* FUTURE-USE */
|
2003-03-18 00:07:40 +01:00
|
|
|
%token SEPARATOR_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token SERIALIZABLE_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token SERIAL_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token SESSION_SYM /* SQL-2003-N */
|
2006-12-02 01:47:45 +01:00
|
|
|
%token SERVER_SYM
|
|
|
|
%token SERVER_OPTIONS
|
2006-11-02 19:01:53 +01:00
|
|
|
%token SET /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token SET_VAR
|
|
|
|
%token SHARE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token SHIFT_LEFT /* OPERATOR */
|
|
|
|
%token SHIFT_RIGHT /* OPERATOR */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token SHOW
|
|
|
|
%token SHUTDOWN
|
|
|
|
%token SIGNED_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token SIMPLE_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token SLAVE
|
2006-11-02 19:01:53 +01:00
|
|
|
%token SMALLINT /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token SNAPSHOT_SYM
|
2006-12-02 01:47:45 +01:00
|
|
|
%token SOCKET_SYM
|
2005-11-06 13:13:06 +01:00
|
|
|
%token SONAME_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token SOUNDS_SYM
|
|
|
|
%token SPATIAL_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token SPECIFIC_SYM /* SQL-2003-R */
|
|
|
|
%token SQLEXCEPTION_SYM /* SQL-2003-R */
|
|
|
|
%token SQLSTATE_SYM /* SQL-2003-R */
|
|
|
|
%token SQLWARNING_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token SQL_BIG_RESULT
|
|
|
|
%token SQL_BUFFER_RESULT
|
|
|
|
%token SQL_CACHE_SYM
|
|
|
|
%token SQL_CALC_FOUND_ROWS
|
|
|
|
%token SQL_NO_CACHE_SYM
|
|
|
|
%token SQL_SMALL_RESULT
|
2006-11-02 19:01:53 +01:00
|
|
|
%token SQL_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token SQL_THREAD
|
2001-09-30 04:46:20 +02:00
|
|
|
%token SSL_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token STARTING
|
2005-12-02 13:07:02 +01:00
|
|
|
%token STARTS_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token START_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token STATUS_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token STDDEV_SAMP_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token STD_SYM
|
|
|
|
%token STOP_SYM
|
|
|
|
%token STORAGE_SYM
|
|
|
|
%token STRAIGHT_JOIN
|
|
|
|
%token STRING_SYM
|
|
|
|
%token SUBDATE_SYM
|
|
|
|
%token SUBJECT_SYM
|
2005-07-18 13:31:02 +02:00
|
|
|
%token SUBPARTITIONS_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token SUBPARTITION_SYM
|
|
|
|
%token SUBSTRING /* SQL-2003-N */
|
|
|
|
%token SUM_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token SUPER_SYM
|
|
|
|
%token SUSPEND_SYM
|
2005-08-25 00:50:58 +02:00
|
|
|
%token SYSDATE
|
2005-01-16 13:16:23 +01:00
|
|
|
%token TABLES
|
|
|
|
%token TABLESPACE
|
2006-11-02 19:01:53 +01:00
|
|
|
%token TABLE_REF_PRIORITY
|
|
|
|
%token TABLE_SYM /* SQL-2003-R */
|
|
|
|
%token TEMPORARY /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token TEMPTABLE_SYM
|
|
|
|
%token TERMINATED
|
|
|
|
%token TEXT_STRING
|
|
|
|
%token TEXT_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token THAN_SYM
|
|
|
|
%token THEN_SYM /* SQL-2003-R */
|
|
|
|
%token TIMESTAMP /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token TIMESTAMP_ADD
|
|
|
|
%token TIMESTAMP_DIFF
|
2006-11-02 19:01:53 +01:00
|
|
|
%token TIME_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token TINYBLOB
|
|
|
|
%token TINYINT
|
|
|
|
%token TINYTEXT
|
2006-11-02 19:01:53 +01:00
|
|
|
%token TO_SYM /* SQL-2003-R */
|
|
|
|
%token TRAILING /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token TRANSACTION_SYM
|
2005-07-19 18:06:49 +02:00
|
|
|
%token TRIGGERS_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token TRIGGER_SYM /* SQL-2003-R */
|
|
|
|
%token TRIM /* SQL-2003-N */
|
|
|
|
%token TRUE_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token TRUNCATE_SYM
|
2002-06-12 23:13:12 +02:00
|
|
|
%token TYPES_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token TYPE_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token UDF_RETURNS_SYM
|
|
|
|
%token ULONGLONG_NUM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token UNCOMMITTED_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token UNDEFINED_SYM
|
|
|
|
%token UNDERSCORE_CHARSET
|
2006-11-02 19:01:53 +01:00
|
|
|
%token UNDOFILE_SYM
|
|
|
|
%token UNDO_BUFFER_SIZE_SYM
|
|
|
|
%token UNDO_SYM /* FUTURE-USE */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token UNICODE_SYM
|
2005-11-06 13:13:06 +01:00
|
|
|
%token UNINSTALL_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token UNION_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token UNIQUE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token UNKNOWN_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token UNLOCK_SYM
|
|
|
|
%token UNSIGNED
|
|
|
|
%token UNTIL_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token UPDATE_SYM /* SQL-2003-R */
|
2006-02-17 07:52:32 +01:00
|
|
|
%token UPGRADE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token USAGE /* SQL-2003-N */
|
|
|
|
%token USER /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token USE_FRM
|
|
|
|
%token USE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token USING /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token UTC_DATE_SYM
|
|
|
|
%token UTC_TIMESTAMP_SYM
|
|
|
|
%token UTC_TIME_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token VALUES /* SQL-2003-R */
|
|
|
|
%token VALUE_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token VARBINARY
|
2006-11-02 19:01:53 +01:00
|
|
|
%token VARCHAR /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token VARIABLES
|
|
|
|
%token VARIANCE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token VARYING /* SQL-2003-R */
|
|
|
|
%token VAR_SAMP_SYM
|
|
|
|
%token VIEW_SYM /* SQL-2003-N */
|
2006-01-11 11:35:25 +01:00
|
|
|
%token WAIT_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token WARNINGS
|
|
|
|
%token WEEK_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token WHEN_SYM /* SQL-2003-R */
|
|
|
|
%token WHERE /* SQL-2003-R */
|
2004-11-12 04:01:46 +01:00
|
|
|
%token WHILE_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token WITH /* SQL-2003-R */
|
|
|
|
%token WORK_SYM /* SQL-2003-N */
|
2006-12-02 01:47:45 +01:00
|
|
|
%token WRAPPER_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token WRITE_SYM /* SQL-2003-N */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token X509_SYM
|
|
|
|
%token XA_SYM
|
|
|
|
%token XOR
|
|
|
|
%token YEAR_MONTH_SYM
|
2006-11-02 19:01:53 +01:00
|
|
|
%token YEAR_SYM /* SQL-2003-R */
|
2005-01-16 13:16:23 +01:00
|
|
|
%token ZEROFILL
|
2001-09-20 03:45:13 +02:00
|
|
|
|
2005-10-25 08:00:57 +02:00
|
|
|
%left JOIN_SYM INNER_SYM STRAIGHT_JOIN CROSS LEFT RIGHT
|
2005-09-10 14:01:54 +02:00
|
|
|
/* A dummy token to force the priority of table_ref production in a join. */
|
|
|
|
%left TABLE_REF_PRIORITY
|
2000-07-31 21:29:14 +02:00
|
|
|
%left SET_VAR
|
2004-11-17 16:49:10 +01:00
|
|
|
%left OR_OR_SYM OR_SYM OR2_SYM XOR
|
|
|
|
%left AND_SYM AND_AND_SYM
|
2000-07-31 21:29:14 +02:00
|
|
|
%left BETWEEN_SYM CASE_SYM WHEN_SYM THEN_SYM ELSE
|
|
|
|
%left EQ EQUAL_SYM GE GT_SYM LE LT NE IS LIKE REGEXP IN_SYM
|
|
|
|
%left '|'
|
|
|
|
%left '&'
|
|
|
|
%left SHIFT_LEFT SHIFT_RIGHT
|
|
|
|
%left '-' '+'
|
2002-11-21 01:07:14 +01:00
|
|
|
%left '*' '/' '%' DIV_SYM MOD_SYM
|
2002-06-29 15:25:09 +02:00
|
|
|
%left '^'
|
2003-12-19 15:25:50 +01:00
|
|
|
%left NEG '~'
|
2004-11-17 16:49:10 +01:00
|
|
|
%right NOT_SYM NOT2_SYM
|
2002-08-22 15:12:45 +02:00
|
|
|
%right BINARY COLLATE_SYM
|
2002-10-15 16:33:06 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
%type <lex_str>
|
2005-02-08 23:50:45 +01:00
|
|
|
IDENT IDENT_QUOTED TEXT_STRING DECIMAL_NUM FLOAT_NUM NUM LONG_NUM HEX_NUM
|
2003-11-03 13:01:59 +01:00
|
|
|
LEX_HOSTNAME ULONGLONG_NUM field_ident select_alias ident ident_or_text
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
IDENT_sys TEXT_STRING_sys TEXT_STRING_literal
|
2003-11-18 12:47:27 +01:00
|
|
|
NCHAR_STRING opt_component key_cache_name
|
2006-10-16 18:57:33 +02:00
|
|
|
sp_opt_label BIN_NUM label_ident TEXT_STRING_filesystem ident_or_empty
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
%type <lex_str_ptr>
|
2006-05-03 14:59:17 +02:00
|
|
|
opt_table_alias
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
%type <table>
|
2005-01-16 13:16:23 +01:00
|
|
|
table_ident table_ident_nodb references xid
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
%type <simple_string>
|
2002-11-21 01:07:14 +01:00
|
|
|
remember_name remember_end opt_ident opt_db text_or_password
|
2006-10-16 18:57:33 +02:00
|
|
|
opt_constraint constraint
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
%type <string>
|
2003-03-18 00:07:40 +01:00
|
|
|
text_string opt_gconcat_separator
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
%type <num>
|
2005-03-16 02:32:47 +01:00
|
|
|
type int_type real_type order_dir lock_option
|
2000-07-31 21:29:14 +02:00
|
|
|
udf_type if_exists opt_local opt_table_options table_options
|
2005-08-27 15:51:11 +02:00
|
|
|
table_option opt_if_not_exists opt_no_write_to_binlog
|
|
|
|
delete_option opt_temporary all_or_any opt_distinct
|
2004-03-23 14:43:24 +01:00
|
|
|
opt_ignore_leaves fulltext_options spatial_type union_option
|
2005-02-14 21:50:09 +01:00
|
|
|
start_transaction_opts opt_chain opt_release
|
2005-08-27 15:51:11 +02:00
|
|
|
union_opt select_derived_init option_type2
|
2006-02-14 13:19:54 +01:00
|
|
|
opt_natural_language_mode opt_query_expansion
|
|
|
|
opt_ev_status opt_ev_on_completion ev_on_completion opt_ev_comment
|
|
|
|
ev_alter_on_schedule_completion opt_ev_rename_to opt_ev_sql_stmt
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
%type <ulong_num>
|
2006-08-07 18:02:28 +02:00
|
|
|
ulong_num real_ulong_num merge_insert_types
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-09-14 01:54:33 +02:00
|
|
|
%type <ulonglong_number>
|
2006-08-07 18:02:28 +02:00
|
|
|
ulonglong_num real_ulonglong_num size_number
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2006-03-07 12:25:08 +01:00
|
|
|
%type <p_elem_value>
|
2005-07-22 20:47:05 +02:00
|
|
|
part_bit_expr
|
|
|
|
|
2002-11-16 19:19:10 +01:00
|
|
|
%type <lock_type>
|
|
|
|
replace_lock_option opt_low_priority insert_lock_option load_data_lock
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
%type <item>
|
2001-12-10 16:51:07 +01:00
|
|
|
literal text_literal insert_ident order_ident
|
2000-07-31 21:29:14 +02:00
|
|
|
simple_ident select_item2 expr opt_expr opt_else sum_expr in_sum_expr
|
2006-10-12 16:02:57 +02:00
|
|
|
variable variable_aux bool_term bool_factor bool_test bool_pri
|
2004-11-17 16:49:10 +01:00
|
|
|
predicate bit_expr bit_term bit_factor value_expr term factor
|
|
|
|
table_wild simple_expr udf_expr
|
2005-08-12 16:57:19 +02:00
|
|
|
expr_or_default set_expr_or_default interval_expr
|
2006-08-31 17:00:25 +02:00
|
|
|
param_marker geometry_function
|
2004-06-22 17:27:16 +02:00
|
|
|
signed_literal now_or_signed_literal opt_escape
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_opt_default
|
|
|
|
simple_ident_nospvar simple_ident_q
|
2005-06-07 12:11:36 +02:00
|
|
|
field_or_var limit_option
|
2005-07-22 20:47:05 +02:00
|
|
|
part_func_expr
|
2006-11-02 19:01:53 +01:00
|
|
|
function_call_keyword
|
|
|
|
function_call_nonkeyword
|
|
|
|
function_call_generic
|
|
|
|
function_call_conflict
|
2004-03-18 17:27:03 +01:00
|
|
|
|
|
|
|
%type <item_num>
|
|
|
|
NUM_literal
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
%type <item_list>
|
2004-11-12 04:01:46 +01:00
|
|
|
expr_list udf_expr_list udf_expr_list2 when_list
|
2006-10-24 14:26:41 +02:00
|
|
|
ident_list ident_list_arg opt_expr_list
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-08-27 15:51:11 +02:00
|
|
|
%type <var_type>
|
|
|
|
option_type opt_var_type opt_var_ident_type
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
%type <key_type>
|
2003-12-02 16:06:24 +01:00
|
|
|
key_type opt_unique_or_fulltext constraint_key_type
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-02-22 12:24:42 +01:00
|
|
|
%type <key_alg>
|
2006-05-08 22:06:16 +02:00
|
|
|
btree_or_rtree
|
2002-02-22 12:24:42 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
%type <string_list>
|
2007-03-05 18:08:41 +01:00
|
|
|
using_list
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
%type <key_part>
|
|
|
|
key_part
|
|
|
|
|
|
|
|
%type <table_list>
|
2002-10-30 12:18:52 +01:00
|
|
|
join_table_list join_table
|
2004-11-12 04:01:46 +01:00
|
|
|
table_factor table_ref
|
2005-03-16 01:13:23 +01:00
|
|
|
select_derived derived_table_list
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-11-03 13:01:59 +01:00
|
|
|
%type <date_time_type> date_time_type;
|
2000-07-31 21:29:14 +02:00
|
|
|
%type <interval> interval
|
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
%type <interval_time_st> interval_time_st
|
|
|
|
|
Bug#24392 (SHOW ENGINE MUTEX STATUS is a synonym for SHOW INNODB STATUS)
Before this fix, the command SHOW ENGINE <name> STATUS would:
- print a warning if the engine name is unknown,
- proceed and implement the same behavior as SHOW ENGINE ALL STATUS,
and list the status of all the storage engines registered.
In particular, this behavior caused confusion about the command :
SHOW ENGINE MUTEX STATUS, which as a side effect would print the status
of the innodb engine when that engine is registered.
Also, before this fix, every time an unknown engine name was substituted by
the default engine (which happen unless SQL_MODE NO_ENGINE_SUBSTITUTION is
set), a malformed warning was raised.
For example, the command ALTER TABLE T1 ENGINE = X would print :
Warnings:
Error 1286 Unknown table engine 'X'
With this fix:
SHOW ENGINE <name> STATUS|LOGS|MUTEX
always fails with an error when the engine <name> is unknown.
For other commands, warnings about unknown engines are raised as:
Warnings:
Warning 1286 Unknown table engine 'X'
In other words, engine substitution never affect the SHOW ENGINE command,
since this would lead to very confusing results.
2007-01-23 23:14:08 +01:00
|
|
|
%type <db_type> storage_engines known_storage_engines
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
%type <row_type> row_types
|
|
|
|
|
2002-07-23 17:31:22 +02:00
|
|
|
%type <tx_isolation> isolation_types
|
2001-03-21 00:02:22 +01:00
|
|
|
|
2001-11-05 23:05:45 +01:00
|
|
|
%type <ha_rkey_mode> handler_rkey_mode
|
|
|
|
|
2004-01-22 21:13:24 +01:00
|
|
|
%type <cast_type> cast_type
|
2002-01-02 23:46:43 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
%type <udf_type> udf_func_type
|
|
|
|
|
2006-11-02 19:01:53 +01:00
|
|
|
%type <symbol> keyword keyword_sp
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2006-03-01 12:13:07 +01:00
|
|
|
%type <lex_user> user grant_user
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-12-04 23:14:51 +01:00
|
|
|
%type <charset>
|
2003-03-05 09:37:39 +01:00
|
|
|
opt_collate
|
2002-09-12 16:36:22 +02:00
|
|
|
charset_name
|
|
|
|
charset_name_or_default
|
2003-04-05 15:56:15 +02:00
|
|
|
old_or_new_charset_name
|
|
|
|
old_or_new_charset_name_or_default
|
2003-01-09 12:37:59 +01:00
|
|
|
collation_name
|
|
|
|
collation_name_or_default
|
2007-02-28 14:06:57 +01:00
|
|
|
opt_load_data_charset
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
UNDERSCORE_CHARSET
|
2002-09-12 16:36:22 +02:00
|
|
|
|
2002-07-23 17:31:22 +02:00
|
|
|
%type <variable> internal_variable_name
|
|
|
|
|
2006-08-31 17:00:25 +02:00
|
|
|
%type <select_lex> subselect subselect_init
|
2005-03-16 01:13:23 +01:00
|
|
|
get_select_lex
|
2002-10-27 22:27:00 +01:00
|
|
|
|
2002-11-07 22:45:19 +01:00
|
|
|
%type <boolfunc2creator> comp_op
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
%type <NONE>
|
2001-12-17 18:59:20 +01:00
|
|
|
query verb_clause create change select do drop insert replace insert2
|
2000-11-13 22:55:10 +01:00
|
|
|
insert_values update delete truncate rename
|
2003-08-26 09:15:49 +02:00
|
|
|
show describe load alter optimize keycache preload flush
|
2005-02-01 20:48:05 +01:00
|
|
|
reset purge begin commit rollback savepoint release
|
2003-11-28 11:18:13 +01:00
|
|
|
slave master_def master_defs master_file_def slave_until_opts
|
2003-08-21 16:15:06 +02:00
|
|
|
repair restore backup analyze check start checksum
|
2003-02-22 01:07:17 +01:00
|
|
|
field_list field_list_item field_spec kill column_def key_def
|
2003-08-26 09:15:49 +02:00
|
|
|
keycache_list assign_to_keycache preload_list preload_keys
|
2000-07-31 21:29:14 +02:00
|
|
|
select_item_list select_item values_list no_braces
|
2002-11-28 17:25:41 +01:00
|
|
|
opt_limit_clause delete_limit_clause fields opt_values values
|
2000-07-31 21:29:14 +02:00
|
|
|
procedure_list procedure_list2 procedure_item
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
expr_list2 udf_expr_list3 handler
|
2000-07-31 21:29:14 +02:00
|
|
|
opt_precision opt_ignore opt_column opt_restrict
|
|
|
|
grant revoke set lock unlock string_list field_options field_option
|
2003-03-20 17:04:21 +01:00
|
|
|
field_opt_list opt_binary table_lock_list table_lock
|
2002-06-02 20:22:20 +02:00
|
|
|
ref_list opt_on_delete opt_on_delete_list opt_on_delete_item use
|
2003-03-20 17:04:21 +01:00
|
|
|
opt_delete_options opt_delete_option varchar nchar nvarchar
|
2002-11-16 19:19:10 +01:00
|
|
|
opt_outer table_list table_name opt_option opt_place
|
2000-07-31 21:29:14 +02:00
|
|
|
opt_attribute opt_attribute_list attribute column_list column_list_id
|
2005-05-17 20:54:20 +02:00
|
|
|
opt_column_list grant_privileges grant_ident grant_list grant_option
|
2004-12-23 11:46:24 +01:00
|
|
|
object_privilege object_privilege_list user_list rename_list
|
2004-11-25 21:55:49 +01:00
|
|
|
clear_privileges flush_options flush_option
|
2007-03-05 18:08:41 +01:00
|
|
|
equal optional_braces
|
2000-07-31 21:29:14 +02:00
|
|
|
opt_mi_check_type opt_to mi_check_types normal_join
|
2006-02-13 08:49:28 +01:00
|
|
|
db_to_db table_to_table_list table_to_table opt_table_list opt_as
|
2001-11-05 23:05:45 +01:00
|
|
|
handler_rkey_function handler_read_or_scan
|
2002-11-21 14:56:48 +01:00
|
|
|
single_multi table_wild_list table_wild_one opt_wild
|
2004-03-23 14:43:24 +01:00
|
|
|
union_clause union_list
|
2003-03-05 13:43:10 +01:00
|
|
|
precision subselect_start opt_and charset
|
2002-11-21 01:07:14 +01:00
|
|
|
subselect_end select_var_list select_var_list_init help opt_len
|
2004-04-06 12:00:51 +02:00
|
|
|
opt_extended_describe
|
2005-09-14 09:53:09 +02:00
|
|
|
prepare prepare_src execute deallocate
|
2005-11-10 20:25:03 +01:00
|
|
|
statement sp_suid
|
2005-01-16 13:16:23 +01:00
|
|
|
sp_c_chistics sp_a_chistics sp_chistic sp_c_chistic xa
|
2005-03-16 02:32:47 +01:00
|
|
|
load_data opt_field_or_var_spec fields_or_vars opt_load_data_set_spec
|
2007-03-09 13:52:50 +01:00
|
|
|
definer view_replace_or_algorithm view_replace
|
2006-06-27 13:15:40 +02:00
|
|
|
view_algorithm view_or_trigger_or_sp_or_event
|
|
|
|
view_or_trigger_or_sp_or_event_tail
|
2006-03-09 18:41:21 +01:00
|
|
|
view_suid view_tail view_list_opt view_list view_select
|
|
|
|
view_check_option trigger_tail sp_tail
|
2005-12-26 14:22:12 +01:00
|
|
|
install uninstall partition_entry binlog_base64_event
|
2006-05-08 22:06:16 +02:00
|
|
|
init_key_options key_options key_opts key_opt key_using_alg
|
2006-12-02 01:47:45 +01:00
|
|
|
server_def server_options_list server_option
|
2001-06-03 16:07:26 +02:00
|
|
|
END_OF_INPUT
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
%type <NONE> call sp_proc_stmts sp_proc_stmts1 sp_proc_stmt
|
2005-12-02 13:07:02 +01:00
|
|
|
%type <NONE> sp_proc_stmt_statement sp_proc_stmt_return
|
2006-12-12 21:50:55 +01:00
|
|
|
%type <NONE> sp_proc_stmt_if
|
2005-12-02 13:07:02 +01:00
|
|
|
%type <NONE> sp_labeled_control sp_proc_stmt_unlabeled sp_proc_stmt_leave
|
2006-04-25 17:44:35 +02:00
|
|
|
%type <NONE> sp_proc_stmt_iterate
|
2005-12-02 13:07:02 +01:00
|
|
|
%type <NONE> sp_proc_stmt_open sp_proc_stmt_fetch sp_proc_stmt_close
|
2006-12-12 21:50:55 +01:00
|
|
|
%type <NONE> case_stmt_specification simple_case_stmt searched_case_stmt
|
2005-12-02 13:07:02 +01:00
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
%type <num> sp_decl_idents sp_opt_inout sp_handler_type sp_hcond_list
|
|
|
|
%type <spcondtype> sp_cond sp_hcond
|
|
|
|
%type <spblock> sp_decls sp_decl
|
|
|
|
%type <lex> sp_cursor_stmt
|
|
|
|
%type <spname> sp_name
|
2007-03-05 18:08:41 +01:00
|
|
|
%type <index_hint> index_hint_type
|
|
|
|
%type <num> index_hint_clause
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
%type <NONE>
|
|
|
|
'-' '+' '*' '/' '%' '(' ')'
|
2004-11-17 16:49:10 +01:00
|
|
|
',' '!' '{' '}' '&' '|' AND_SYM OR_SYM OR_OR_SYM BETWEEN_SYM CASE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
THEN_SYM WHEN_SYM DIV_SYM MOD_SYM OR2_SYM AND_AND_SYM
|
2000-07-31 21:29:14 +02:00
|
|
|
%%
|
|
|
|
|
|
|
|
|
|
|
|
query:
|
|
|
|
END_OF_INPUT
|
2001-03-25 00:02:26 +01:00
|
|
|
{
|
2002-11-26 14:18:16 +01:00
|
|
|
THD *thd= YYTHD;
|
2002-02-14 14:04:14 +01:00
|
|
|
if (!thd->bootstrap &&
|
2003-12-19 18:52:13 +01:00
|
|
|
(!(thd->lex->select_lex.options & OPTION_FOUND_COMMENT)))
|
2002-02-14 14:04:14 +01:00
|
|
|
{
|
2004-11-12 13:34:00 +01:00
|
|
|
my_message(ER_EMPTY_QUERY, ER(ER_EMPTY_QUERY), MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-11-29 16:17:52 +01:00
|
|
|
}
|
2002-02-14 14:04:14 +01:00
|
|
|
else
|
|
|
|
{
|
2003-12-19 18:52:13 +01:00
|
|
|
thd->lex->sql_command= SQLCOM_EMPTY_QUERY;
|
2002-02-14 14:04:14 +01:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-04-16 01:09:30 +02:00
|
|
|
| verb_clause END_OF_INPUT {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
verb_clause:
|
2004-11-12 04:01:46 +01:00
|
|
|
statement
|
|
|
|
| begin
|
|
|
|
;
|
|
|
|
|
|
|
|
/* Verb clauses, except begin */
|
|
|
|
statement:
|
2000-07-31 21:29:14 +02:00
|
|
|
alter
|
|
|
|
| analyze
|
2000-10-10 21:31:00 +02:00
|
|
|
| backup
|
2005-12-22 06:39:02 +01:00
|
|
|
| binlog_base64_event
|
2004-11-12 04:01:46 +01:00
|
|
|
| call
|
2000-07-31 21:29:14 +02:00
|
|
|
| change
|
|
|
|
| check
|
2003-08-21 16:15:06 +02:00
|
|
|
| checksum
|
2000-07-31 21:29:14 +02:00
|
|
|
| commit
|
|
|
|
| create
|
2004-06-07 10:09:10 +02:00
|
|
|
| deallocate
|
2000-07-31 21:29:14 +02:00
|
|
|
| delete
|
|
|
|
| describe
|
2001-12-17 18:59:20 +01:00
|
|
|
| do
|
2000-07-31 21:29:14 +02:00
|
|
|
| drop
|
2004-06-07 10:09:10 +02:00
|
|
|
| execute
|
2003-08-05 21:14:15 +02:00
|
|
|
| flush
|
2000-07-31 21:29:14 +02:00
|
|
|
| grant
|
2003-08-05 21:14:15 +02:00
|
|
|
| handler
|
|
|
|
| help
|
2000-07-31 21:29:14 +02:00
|
|
|
| insert
|
2005-11-06 13:13:06 +01:00
|
|
|
| install
|
2003-08-05 21:14:15 +02:00
|
|
|
| kill
|
2000-07-31 21:29:14 +02:00
|
|
|
| load
|
|
|
|
| lock
|
|
|
|
| optimize
|
2003-08-26 09:15:49 +02:00
|
|
|
| keycache
|
2005-07-18 13:31:02 +02:00
|
|
|
| partition_entry
|
2003-06-12 13:29:02 +02:00
|
|
|
| preload
|
2004-06-07 10:09:10 +02:00
|
|
|
| prepare
|
2002-12-04 23:14:51 +01:00
|
|
|
| purge
|
2005-02-01 20:48:05 +01:00
|
|
|
| release
|
2000-08-21 02:00:52 +02:00
|
|
|
| rename
|
2003-08-05 21:14:15 +02:00
|
|
|
| repair
|
2000-07-31 21:29:14 +02:00
|
|
|
| replace
|
2000-10-14 10:16:17 +02:00
|
|
|
| reset
|
2000-10-10 21:31:00 +02:00
|
|
|
| restore
|
2000-07-31 21:29:14 +02:00
|
|
|
| revoke
|
|
|
|
| rollback
|
2003-06-06 03:18:58 +02:00
|
|
|
| savepoint
|
2000-07-31 21:29:14 +02:00
|
|
|
| select
|
|
|
|
| set
|
2003-08-05 21:14:15 +02:00
|
|
|
| show
|
2000-08-21 23:39:08 +02:00
|
|
|
| slave
|
2003-02-06 15:55:59 +01:00
|
|
|
| start
|
2000-11-13 22:55:10 +01:00
|
|
|
| truncate
|
2005-11-06 13:13:06 +01:00
|
|
|
| uninstall
|
2000-07-31 21:29:14 +02:00
|
|
|
| unlock
|
|
|
|
| update
|
2002-10-28 14:44:19 +01:00
|
|
|
| use
|
2005-01-16 13:16:23 +01:00
|
|
|
| xa
|
2003-08-05 21:14:15 +02:00
|
|
|
;
|
2002-12-04 23:14:51 +01:00
|
|
|
|
2004-04-05 17:43:37 +02:00
|
|
|
deallocate:
|
2004-06-18 02:02:29 +02:00
|
|
|
deallocate_or_drop PREPARE_SYM ident
|
2004-04-05 17:43:37 +02:00
|
|
|
{
|
2007-01-27 02:46:45 +01:00
|
|
|
THD *thd= YYTHD;
|
2004-04-30 18:08:38 +02:00
|
|
|
LEX *lex= thd->lex;
|
|
|
|
lex->sql_command= SQLCOM_DEALLOCATE_PREPARE;
|
2004-04-05 17:43:37 +02:00
|
|
|
lex->prepared_stmt_name= $3;
|
|
|
|
};
|
|
|
|
|
2004-06-18 02:02:29 +02:00
|
|
|
deallocate_or_drop:
|
|
|
|
DEALLOCATE_SYM |
|
|
|
|
DROP
|
|
|
|
;
|
|
|
|
|
|
|
|
|
2004-04-05 17:43:37 +02:00
|
|
|
prepare:
|
2004-05-21 02:27:50 +02:00
|
|
|
PREPARE_SYM ident FROM prepare_src
|
2004-04-05 17:43:37 +02:00
|
|
|
{
|
2007-01-27 02:46:45 +01:00
|
|
|
THD *thd= YYTHD;
|
2004-04-30 18:08:38 +02:00
|
|
|
LEX *lex= thd->lex;
|
|
|
|
lex->sql_command= SQLCOM_PREPARE;
|
2004-04-05 17:43:37 +02:00
|
|
|
lex->prepared_stmt_name= $2;
|
|
|
|
};
|
|
|
|
|
2004-05-21 02:27:50 +02:00
|
|
|
prepare_src:
|
|
|
|
TEXT_STRING_sys
|
|
|
|
{
|
2007-01-27 02:46:45 +01:00
|
|
|
THD *thd= YYTHD;
|
2004-05-21 02:27:50 +02:00
|
|
|
LEX *lex= thd->lex;
|
|
|
|
lex->prepared_stmt_code= $1;
|
2004-10-14 17:03:46 +02:00
|
|
|
lex->prepared_stmt_code_is_varref= FALSE;
|
2004-05-21 02:27:50 +02:00
|
|
|
}
|
|
|
|
| '@' ident_or_text
|
|
|
|
{
|
2007-01-27 02:46:45 +01:00
|
|
|
THD *thd= YYTHD;
|
2004-05-21 02:27:50 +02:00
|
|
|
LEX *lex= thd->lex;
|
|
|
|
lex->prepared_stmt_code= $2;
|
2004-10-14 17:03:46 +02:00
|
|
|
lex->prepared_stmt_code_is_varref= TRUE;
|
2004-05-21 02:27:50 +02:00
|
|
|
};
|
2004-06-07 10:09:10 +02:00
|
|
|
|
2004-04-05 17:43:37 +02:00
|
|
|
execute:
|
|
|
|
EXECUTE_SYM ident
|
|
|
|
{
|
2007-01-27 02:46:45 +01:00
|
|
|
THD *thd= YYTHD;
|
2004-04-30 18:08:38 +02:00
|
|
|
LEX *lex= thd->lex;
|
|
|
|
lex->sql_command= SQLCOM_EXECUTE;
|
2004-04-05 17:43:37 +02:00
|
|
|
lex->prepared_stmt_name= $2;
|
|
|
|
}
|
|
|
|
execute_using
|
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
|
|
|
execute_using:
|
|
|
|
/* nothing */
|
|
|
|
| USING execute_var_list
|
|
|
|
;
|
|
|
|
|
|
|
|
execute_var_list:
|
2004-04-30 18:08:38 +02:00
|
|
|
execute_var_list ',' execute_var_ident
|
|
|
|
| execute_var_ident
|
2004-04-05 17:43:37 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
execute_var_ident: '@' ident_or_text
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
LEX_STRING *lexstr= (LEX_STRING*)sql_memdup(&$2, sizeof(LEX_STRING));
|
|
|
|
if (!lexstr || lex->prepared_stmt_params.push_back(lexstr))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-04-30 18:08:38 +02:00
|
|
|
}
|
2004-04-05 17:43:37 +02:00
|
|
|
;
|
|
|
|
|
2002-10-28 14:44:19 +01:00
|
|
|
/* help */
|
|
|
|
|
2002-12-04 23:14:51 +01:00
|
|
|
help:
|
2005-08-29 12:19:08 +02:00
|
|
|
HELP_SYM
|
|
|
|
{
|
|
|
|
if (Lex->sphead)
|
|
|
|
{
|
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "HELP");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-08-29 12:19:08 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
ident_or_text
|
2002-10-28 14:44:19 +01:00
|
|
|
{
|
2003-02-12 20:55:37 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command= SQLCOM_HELP;
|
2005-08-29 12:19:08 +02:00
|
|
|
lex->help_arg= $3.str;
|
2002-10-30 14:38:07 +01:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
/* change master */
|
|
|
|
|
|
|
|
change:
|
2000-08-21 23:39:08 +02:00
|
|
|
CHANGE MASTER_SYM TO_SYM
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
|
|
|
LEX *lex = Lex;
|
|
|
|
lex->sql_command = SQLCOM_CHANGE_MASTER;
|
2002-10-29 20:59:03 +01:00
|
|
|
bzero((char*) &lex->mi, sizeof(lex->mi));
|
2002-11-28 18:57:56 +01:00
|
|
|
}
|
|
|
|
master_defs
|
|
|
|
{}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
master_defs:
|
|
|
|
master_def
|
2002-07-23 17:31:22 +02:00
|
|
|
| master_defs ',' master_def;
|
2000-08-21 23:39:08 +02:00
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
master_def:
|
|
|
|
MASTER_HOST_SYM EQ TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->mi.host = $3.str;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
MASTER_USER_SYM EQ TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->mi.user = $3.str;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
MASTER_PASSWORD_SYM EQ TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->mi.password = $3.str;
|
|
|
|
}
|
|
|
|
|
|
2005-04-04 00:50:05 +02:00
|
|
|
MASTER_PORT_SYM EQ ulong_num
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
Lex->mi.port = $3;
|
|
|
|
}
|
|
|
|
|
|
2005-04-04 00:50:05 +02:00
|
|
|
MASTER_CONNECT_RETRY_SYM EQ ulong_num
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
Lex->mi.connect_retry = $3;
|
|
|
|
}
|
2005-04-04 00:50:05 +02:00
|
|
|
| MASTER_SSL_SYM EQ ulong_num
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
Lex->mi.ssl= $3 ?
|
|
|
|
LEX_MASTER_INFO::SSL_ENABLE : LEX_MASTER_INFO::SSL_DISABLE;
|
|
|
|
}
|
|
|
|
| MASTER_SSL_CA_SYM EQ TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->mi.ssl_ca= $3.str;
|
|
|
|
}
|
|
|
|
| MASTER_SSL_CAPATH_SYM EQ TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->mi.ssl_capath= $3.str;
|
|
|
|
}
|
|
|
|
| MASTER_SSL_CERT_SYM EQ TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->mi.ssl_cert= $3.str;
|
|
|
|
}
|
|
|
|
| MASTER_SSL_CIPHER_SYM EQ TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->mi.ssl_cipher= $3.str;
|
|
|
|
}
|
|
|
|
| MASTER_SSL_KEY_SYM EQ TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->mi.ssl_key= $3.str;
|
|
|
|
}
|
2007-03-29 15:09:57 +02:00
|
|
|
| MASTER_SSL_VERIFY_SERVER_CERT_SYM EQ ulong_num
|
|
|
|
{
|
|
|
|
Lex->mi.ssl_verify_server_cert= $3 ?
|
|
|
|
LEX_MASTER_INFO::SSL_ENABLE : LEX_MASTER_INFO::SSL_DISABLE;
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
|
|
|
|
|
master_file_def
|
|
|
|
;
|
|
|
|
|
|
|
|
master_file_def:
|
|
|
|
MASTER_LOG_FILE_SYM EQ TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->mi.log_file_name = $3.str;
|
|
|
|
}
|
|
|
|
| MASTER_LOG_POS_SYM EQ ulonglong_num
|
|
|
|
{
|
|
|
|
Lex->mi.pos = $3;
|
|
|
|
/*
|
|
|
|
If the user specified a value < BIN_LOG_HEADER_SIZE, adjust it
|
|
|
|
instead of causing subsequent errors.
|
|
|
|
We need to do it in this file, because only there we know that
|
|
|
|
MASTER_LOG_POS has been explicitely specified. On the contrary
|
|
|
|
in change_master() (sql_repl.cc) we cannot distinguish between 0
|
|
|
|
(MASTER_LOG_POS explicitely specified as 0) and 0 (unspecified),
|
|
|
|
whereas we want to distinguish (specified 0 means "read the binlog
|
|
|
|
from 0" (4 in fact), unspecified means "don't change the position
|
|
|
|
(keep the preceding value)").
|
|
|
|
*/
|
|
|
|
Lex->mi.pos = max(BIN_LOG_HEADER_SIZE, Lex->mi.pos);
|
|
|
|
}
|
|
|
|
| RELAY_LOG_FILE_SYM EQ TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->mi.relay_log_name = $3.str;
|
|
|
|
}
|
2005-04-04 00:50:05 +02:00
|
|
|
| RELAY_LOG_POS_SYM EQ ulong_num
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
Lex->mi.relay_log_pos = $3;
|
|
|
|
/* Adjust if < BIN_LOG_HEADER_SIZE (same comment as Lex->mi.pos) */
|
|
|
|
Lex->mi.relay_log_pos = max(BIN_LOG_HEADER_SIZE, Lex->mi.relay_log_pos);
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
/* create a table */
|
|
|
|
|
|
|
|
create:
|
|
|
|
CREATE opt_table_options TABLE_SYM opt_if_not_exists table_ident
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
2007-01-27 02:46:45 +01:00
|
|
|
LEX *lex= thd->lex;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->sql_command= SQLCOM_CREATE_TABLE;
|
|
|
|
if (!lex->select_lex.add_table_to_list(thd, $5, NULL,
|
|
|
|
TL_OPTION_UPDATING,
|
2007-05-11 19:51:03 +02:00
|
|
|
TL_WRITE))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
lex->alter_info.reset();
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->col_list.empty();
|
|
|
|
lex->change=NullS;
|
|
|
|
bzero((char*) &lex->create_info,sizeof(lex->create_info));
|
|
|
|
lex->create_info.options=$2 | $4;
|
2007-03-02 17:43:45 +01:00
|
|
|
lex->create_info.db_type= ha_default_handlerton(thd);
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->create_info.default_table_charset= NULL;
|
2006-10-16 18:57:33 +02:00
|
|
|
lex->name.str= 0;
|
|
|
|
lex->name.length= 0;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
create2
|
2007-03-02 17:43:45 +01:00
|
|
|
{
|
|
|
|
LEX *lex= YYTHD->lex;
|
|
|
|
lex->current_select= &lex->select_lex;
|
|
|
|
if (!lex->create_info.db_type)
|
|
|
|
{
|
|
|
|
lex->create_info.db_type= ha_default_handlerton(YYTHD);
|
|
|
|
push_warning_printf(YYTHD, MYSQL_ERROR::WARN_LEVEL_WARN,
|
|
|
|
ER_WARN_USING_OTHER_HANDLER,
|
|
|
|
ER(ER_WARN_USING_OTHER_HANDLER),
|
|
|
|
ha_resolve_storage_engine_name(lex->create_info.db_type),
|
|
|
|
$5->table.str);
|
|
|
|
}
|
|
|
|
}
|
2006-05-03 14:59:17 +02:00
|
|
|
| CREATE opt_unique_or_fulltext INDEX_SYM ident key_alg ON
|
|
|
|
table_ident
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_CREATE_INDEX;
|
2006-05-03 14:59:17 +02:00
|
|
|
if (!lex->current_select->add_table_to_list(lex->thd, $7,
|
|
|
|
NULL,
|
2004-11-12 04:01:46 +01:00
|
|
|
TL_OPTION_UPDATING))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
lex->alter_info.reset();
|
|
|
|
lex->alter_info.flags= ALTER_ADD_INDEX;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->col_list.empty();
|
|
|
|
lex->change=NullS;
|
|
|
|
}
|
2006-05-03 14:59:17 +02:00
|
|
|
'(' key_list ')' key_options
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
Key *key;
|
2006-05-03 18:40:52 +02:00
|
|
|
if ($2 != Key::FULLTEXT && lex->key_create_info.parser_name.str)
|
2005-11-06 13:13:06 +01:00
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-11-06 13:13:06 +01:00
|
|
|
}
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
key= new Key($2, $4.str, &lex->key_create_info, 0,
|
|
|
|
lex->col_list);
|
|
|
|
lex->alter_info.key_list.push_back(key);
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->col_list.empty();
|
|
|
|
}
|
|
|
|
| CREATE DATABASE opt_if_not_exists ident
|
|
|
|
{
|
|
|
|
Lex->create_info.default_table_charset= NULL;
|
|
|
|
Lex->create_info.used_fields= 0;
|
|
|
|
}
|
|
|
|
opt_create_database_options
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command=SQLCOM_CREATE_DB;
|
2006-10-16 18:57:33 +02:00
|
|
|
lex->name= $4;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->create_info.options=$3;
|
|
|
|
}
|
2006-06-27 13:15:40 +02:00
|
|
|
| CREATE
|
|
|
|
{
|
|
|
|
Lex->create_view_mode= VIEW_CREATE_NEW;
|
|
|
|
Lex->create_view_algorithm= VIEW_ALGORITHM_UNDEFINED;
|
|
|
|
Lex->create_view_suid= TRUE;
|
|
|
|
}
|
|
|
|
view_or_trigger_or_sp_or_event
|
|
|
|
{}
|
|
|
|
| CREATE USER clear_privileges grant_list
|
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_CREATE_USER;
|
|
|
|
}
|
2007-02-23 21:48:15 +01:00
|
|
|
| CREATE LOGFILE_SYM GROUP_SYM logfile_group_info
|
2006-06-27 13:15:40 +02:00
|
|
|
{
|
2006-08-14 15:26:59 +02:00
|
|
|
Lex->alter_tablespace_info->ts_cmd_type= CREATE_LOGFILE_GROUP;
|
2006-06-27 13:15:40 +02:00
|
|
|
}
|
|
|
|
| CREATE TABLESPACE tablespace_info
|
|
|
|
{
|
2006-08-14 15:26:59 +02:00
|
|
|
Lex->alter_tablespace_info->ts_cmd_type= CREATE_TABLESPACE;
|
2006-06-27 13:15:40 +02:00
|
|
|
}
|
2006-12-02 01:47:45 +01:00
|
|
|
| CREATE server_def
|
|
|
|
{
|
|
|
|
Lex->sql_command= SQLCOM_CREATE_SERVER;
|
|
|
|
}
|
2006-06-27 13:15:40 +02:00
|
|
|
;
|
2006-12-02 01:47:45 +01:00
|
|
|
server_def:
|
|
|
|
SERVER_SYM ident_or_text FOREIGN DATA_SYM WRAPPER_SYM ident_or_text OPTIONS_SYM '(' server_options_list ')'
|
|
|
|
{
|
|
|
|
Lex->server_options.server_name= $2.str;
|
|
|
|
Lex->server_options.server_name_length= $2.length;
|
|
|
|
Lex->server_options.scheme= $6.str;
|
|
|
|
}
|
|
|
|
;
|
2006-06-27 13:15:40 +02:00
|
|
|
|
2006-12-02 01:47:45 +01:00
|
|
|
server_options_list:
|
|
|
|
server_option
|
|
|
|
| server_options_list ',' server_option
|
|
|
|
;
|
|
|
|
|
|
|
|
server_option:
|
|
|
|
USER TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->server_options.username= $2.str;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
HOST_SYM TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->server_options.host= $2.str;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
DATABASE TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->server_options.db= $2.str;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
OWNER_SYM TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->server_options.owner= $2.str;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
PASSWORD TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->server_options.password= $2.str;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
SOCKET_SYM TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->server_options.socket= $2.str;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
PORT_SYM ulong_num
|
|
|
|
{
|
|
|
|
Lex->server_options.port= $2;
|
|
|
|
}
|
|
|
|
;
|
2006-06-27 13:15:40 +02:00
|
|
|
|
|
|
|
event_tail:
|
|
|
|
EVENT_SYM opt_if_not_exists sp_name
|
2006-02-14 13:19:54 +01:00
|
|
|
/*
|
|
|
|
BE CAREFUL when you add a new rule to update the block where
|
2005-12-07 19:26:44 +01:00
|
|
|
YYTHD->client_capabilities is set back to original value
|
|
|
|
*/
|
2005-12-02 13:07:02 +01:00
|
|
|
{
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex=Lex;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
lex->create_info.options= $2;
|
|
|
|
|
|
|
|
if (!(lex->event_parse_data= Event_parse_data::new_instance(thd)))
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
lex->event_parse_data->identifier= $3;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2005-12-02 13:07:02 +01:00
|
|
|
/*
|
|
|
|
We have to turn of CLIENT_MULTI_QUERIES while parsing a
|
|
|
|
stored procedure, otherwise yylex will chop it into pieces
|
|
|
|
at each ';'.
|
|
|
|
*/
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
$<ulong_num>$= thd->client_capabilities & CLIENT_MULTI_QUERIES;
|
|
|
|
thd->client_capabilities &= (~CLIENT_MULTI_QUERIES);
|
2005-12-05 11:45:04 +01:00
|
|
|
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
lex->sql_command= SQLCOM_CREATE_EVENT;
|
2006-08-23 16:53:04 +02:00
|
|
|
/* We need that for disallowing subqueries */
|
2005-12-02 13:07:02 +01:00
|
|
|
}
|
|
|
|
ON SCHEDULE_SYM ev_schedule_time
|
2006-01-20 16:12:44 +01:00
|
|
|
opt_ev_on_completion
|
|
|
|
opt_ev_status
|
|
|
|
opt_ev_comment
|
2005-12-02 13:07:02 +01:00
|
|
|
DO_SYM ev_sql_stmt
|
|
|
|
{
|
2005-12-05 11:45:04 +01:00
|
|
|
/*
|
2005-12-07 19:26:44 +01:00
|
|
|
Restore flag if it was cleared above
|
2006-06-27 13:15:40 +02:00
|
|
|
$1 - EVENT_SYM
|
|
|
|
$2 - opt_if_not_exists
|
|
|
|
$3 - sp_name
|
|
|
|
$4 - the block above
|
2005-12-05 11:45:04 +01:00
|
|
|
*/
|
2006-06-27 13:15:40 +02:00
|
|
|
YYTHD->client_capabilities |= $<ulong_num>4;
|
2005-12-02 13:07:02 +01:00
|
|
|
|
2005-12-07 19:26:44 +01:00
|
|
|
/*
|
|
|
|
sql_command is set here because some rules in ev_sql_stmt
|
|
|
|
can overwrite it
|
|
|
|
*/
|
2005-12-05 11:45:04 +01:00
|
|
|
Lex->sql_command= SQLCOM_CREATE_EVENT;
|
2005-12-02 13:07:02 +01:00
|
|
|
}
|
2006-09-21 09:33:50 +02:00
|
|
|
;
|
2006-01-11 12:49:56 +01:00
|
|
|
|
|
|
|
ev_schedule_time: EVERY_SYM expr interval
|
|
|
|
{
|
2006-06-27 10:53:26 +02:00
|
|
|
Lex->event_parse_data->item_expression= $2;
|
|
|
|
Lex->event_parse_data->interval= $3;
|
2006-01-11 12:49:56 +01:00
|
|
|
}
|
|
|
|
ev_starts
|
|
|
|
ev_ends
|
|
|
|
| AT_SYM expr
|
|
|
|
{
|
2006-06-27 10:53:26 +02:00
|
|
|
Lex->event_parse_data->item_execute_at= $2;
|
2006-01-11 12:49:56 +01:00
|
|
|
}
|
2006-09-21 09:33:50 +02:00
|
|
|
;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
|
|
|
opt_ev_status: /* empty */ { $$= 0; }
|
2006-01-24 16:04:35 +01:00
|
|
|
| ENABLE_SYM
|
2006-01-11 12:49:56 +01:00
|
|
|
{
|
2007-03-16 14:56:57 +01:00
|
|
|
Lex->event_parse_data->status= Event_basic::ENABLED;
|
|
|
|
$$= 1;
|
|
|
|
}
|
2007-03-30 17:08:19 +02:00
|
|
|
| DISABLE_SYM ON SLAVE
|
2007-03-16 14:56:57 +01:00
|
|
|
{
|
|
|
|
Lex->event_parse_data->status= Event_basic::SLAVESIDE_DISABLED;
|
2006-02-14 13:19:54 +01:00
|
|
|
$$= 1;
|
2006-01-11 12:49:56 +01:00
|
|
|
}
|
2006-01-24 16:04:35 +01:00
|
|
|
| DISABLE_SYM
|
2006-01-11 12:49:56 +01:00
|
|
|
{
|
2007-03-16 14:56:57 +01:00
|
|
|
Lex->event_parse_data->status= Event_basic::DISABLED;
|
2006-02-14 13:19:54 +01:00
|
|
|
$$= 1;
|
2006-01-11 12:49:56 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
ev_starts: /* empty */
|
2006-02-28 11:43:10 +01:00
|
|
|
{
|
2006-06-27 10:53:26 +02:00
|
|
|
Lex->event_parse_data->item_starts= new Item_func_now_local();
|
2006-02-28 11:43:10 +01:00
|
|
|
}
|
2006-01-11 12:49:56 +01:00
|
|
|
| STARTS_SYM expr
|
|
|
|
{
|
2006-06-27 10:53:26 +02:00
|
|
|
Lex->event_parse_data->item_starts= $2;
|
2006-01-11 12:49:56 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
ev_ends: /* empty */
|
|
|
|
| ENDS_SYM expr
|
|
|
|
{
|
2006-06-27 10:53:26 +02:00
|
|
|
Lex->event_parse_data->item_ends= $2;
|
2006-01-11 12:49:56 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2006-02-14 13:19:54 +01:00
|
|
|
opt_ev_on_completion: /* empty */ { $$= 0; }
|
2006-01-20 16:12:44 +01:00
|
|
|
| ev_on_completion
|
|
|
|
;
|
|
|
|
|
2006-02-14 13:19:54 +01:00
|
|
|
ev_on_completion:
|
2006-01-20 16:12:44 +01:00
|
|
|
ON COMPLETION_SYM PRESERVE_SYM
|
2005-12-02 13:07:02 +01:00
|
|
|
{
|
2006-06-27 10:53:26 +02:00
|
|
|
Lex->event_parse_data->on_completion=
|
2007-03-16 14:56:57 +01:00
|
|
|
Event_basic::ON_COMPLETION_PRESERVE;
|
2006-02-14 13:19:54 +01:00
|
|
|
$$= 1;
|
2005-12-02 13:07:02 +01:00
|
|
|
}
|
|
|
|
| ON COMPLETION_SYM NOT_SYM PRESERVE_SYM
|
|
|
|
{
|
2006-06-27 10:53:26 +02:00
|
|
|
Lex->event_parse_data->on_completion=
|
2007-03-16 14:56:57 +01:00
|
|
|
Event_basic::ON_COMPLETION_DROP;
|
2006-02-14 13:19:54 +01:00
|
|
|
$$= 1;
|
2005-12-02 13:07:02 +01:00
|
|
|
}
|
|
|
|
;
|
2006-01-11 12:49:56 +01:00
|
|
|
|
2006-02-14 13:19:54 +01:00
|
|
|
opt_ev_comment: /* empty */ { $$= 0; }
|
2005-12-02 13:07:02 +01:00
|
|
|
| COMMENT_SYM TEXT_STRING_sys
|
|
|
|
{
|
2006-06-27 10:53:26 +02:00
|
|
|
Lex->comment= Lex->event_parse_data->comment= $2;
|
2006-10-19 15:56:37 +02:00
|
|
|
$$= 1;
|
2005-12-02 13:07:02 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
ev_sql_stmt:
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2006-06-27 13:15:40 +02:00
|
|
|
/*
|
|
|
|
This stops the following :
|
|
|
|
- CREATE EVENT ... DO CREATE EVENT ...;
|
|
|
|
- ALTER EVENT ... DO CREATE EVENT ...;
|
|
|
|
- CREATE EVENT ... DO ALTER EVENT DO ....;
|
|
|
|
- CREATE PROCEDURE ... BEGIN CREATE EVENT ... END|
|
|
|
|
This allows:
|
|
|
|
- CREATE EVENT ... DO DROP EVENT yyy;
|
|
|
|
- CREATE EVENT ... DO ALTER EVENT yyy;
|
|
|
|
(the nested ALTER EVENT can have anything but DO clause)
|
|
|
|
- ALTER EVENT ... DO ALTER EVENT yyy;
|
|
|
|
(the nested ALTER EVENT can have anything but DO clause)
|
|
|
|
- ALTER EVENT ... DO DROP EVENT yyy;
|
|
|
|
- CREATE PROCEDURE ... BEGIN ALTER EVENT ... END|
|
|
|
|
(the nested ALTER EVENT can have anything but DO clause)
|
|
|
|
- CREATE PROCEDURE ... BEGIN DROP EVENT ... END|
|
|
|
|
*/
|
|
|
|
if (lex->sphead)
|
2005-12-15 14:12:28 +01:00
|
|
|
{
|
2007-03-27 20:15:51 +02:00
|
|
|
my_error(ER_EVENT_RECURSION_FORBIDDEN, MYF(0));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-06-27 13:15:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!(lex->sphead= new sp_head()))
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
lex->sphead->reset_thd_mem_root(thd);
|
2006-06-27 13:15:40 +02:00
|
|
|
lex->sphead->init(lex);
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
lex->sphead->init_sp_name(thd, lex->event_parse_data->identifier);
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2006-06-27 13:15:40 +02:00
|
|
|
lex->sphead->m_type= TYPE_ENUM_PROCEDURE;
|
2005-12-02 13:07:02 +01:00
|
|
|
|
2006-06-27 13:15:40 +02:00
|
|
|
bzero((char *)&lex->sp_chistics, sizeof(st_sp_chistics));
|
|
|
|
lex->sphead->m_chistics= &lex->sp_chistics;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
lex->sphead->set_body_start(thd, lip->get_cpp_ptr());
|
2005-12-02 13:07:02 +01:00
|
|
|
}
|
|
|
|
ev_sql_stmt_inner
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2006-08-17 14:22:59 +02:00
|
|
|
/* return back to the original memory root ASAP */
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
lex->sphead->set_stmt_end(thd);
|
2007-04-26 05:38:12 +02:00
|
|
|
lex->sphead->restore_thd_mem_root(thd);
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2006-08-17 14:22:59 +02:00
|
|
|
lex->sp_chistics.suid= SP_IS_SUID; //always the definer!
|
2005-12-02 13:07:02 +01:00
|
|
|
|
2007-06-14 16:49:17 +02:00
|
|
|
lex->event_parse_data->body_changed= TRUE;
|
2005-12-02 13:07:02 +01:00
|
|
|
}
|
|
|
|
;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2005-12-02 13:07:02 +01:00
|
|
|
ev_sql_stmt_inner:
|
|
|
|
sp_proc_stmt_statement
|
|
|
|
| sp_proc_stmt_return
|
|
|
|
| sp_proc_stmt_if
|
2006-12-13 00:42:35 +01:00
|
|
|
| case_stmt_specification
|
2006-02-14 13:19:54 +01:00
|
|
|
| sp_labeled_control
|
2005-12-02 13:07:02 +01:00
|
|
|
| sp_proc_stmt_unlabeled
|
|
|
|
| sp_proc_stmt_leave
|
|
|
|
| sp_proc_stmt_iterate
|
|
|
|
| sp_proc_stmt_open
|
|
|
|
| sp_proc_stmt_fetch
|
|
|
|
| sp_proc_stmt_close
|
|
|
|
;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2006-01-11 12:49:56 +01:00
|
|
|
|
2004-11-25 21:55:49 +01:00
|
|
|
clear_privileges:
|
|
|
|
/* Nothing */
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->users_list.empty();
|
|
|
|
lex->columns.empty();
|
|
|
|
lex->grant= lex->grant_tot_col= 0;
|
2004-12-23 11:46:24 +01:00
|
|
|
lex->all_privileges= 0;
|
2004-11-25 21:55:49 +01:00
|
|
|
lex->select_lex.db= 0;
|
|
|
|
lex->ssl_type= SSL_TYPE_NOT_SPECIFIED;
|
|
|
|
lex->ssl_cipher= lex->x509_subject= lex->x509_issuer= 0;
|
|
|
|
bzero((char *)&(lex->mqh),sizeof(lex->mqh));
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_name:
|
2005-04-12 15:43:24 +02:00
|
|
|
ident '.' ident
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2006-10-16 18:57:33 +02:00
|
|
|
if (!$1.str || check_db_name(&$1))
|
2006-01-11 15:11:05 +01:00
|
|
|
{
|
|
|
|
my_error(ER_WRONG_DB_NAME, MYF(0), $1.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-11 15:11:05 +01:00
|
|
|
}
|
2007-04-03 13:13:27 +02:00
|
|
|
if (check_routine_name(&$3))
|
2006-01-11 15:11:05 +01:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-11 15:11:05 +01:00
|
|
|
}
|
2007-03-27 18:31:44 +02:00
|
|
|
$$= new sp_name($1, $3, true);
|
2004-11-12 04:01:46 +01:00
|
|
|
$$->init_qname(YYTHD);
|
|
|
|
}
|
2005-04-12 15:43:24 +02:00
|
|
|
| ident
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2007-07-16 22:59:21 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
A fix and a test case for
Bug#19022 "Memory bug when switching db during trigger execution"
Bug#17199 "Problem when view calls function from another database."
Bug#18444 "Fully qualified stored function names don't work correctly in
SELECT statements"
Documentation note: this patch introduces a change in behaviour of prepared
statements.
This patch adds a few new invariants with regard to how THD::db should
be used. These invariants should be preserved in future:
- one should never refer to THD::db by pointer and always make a deep copy
(strmake, strdup)
- one should never compare two databases by pointer, but use strncmp or
my_strncasecmp
- TABLE_LIST object table->db should be always initialized in the parser or
by creator of the object.
For prepared statements it means that if the current database is changed
after a statement is prepared, the database that was current at prepare
remains active. This also means that you can not prepare a statement that
implicitly refers to the current database if the latter is not set.
This is not documented, and therefore needs documentation. This is NOT a
change in behavior for almost all SQL statements except:
- ALTER TABLE t1 RENAME t2
- OPTIMIZE TABLE t1
- ANALYZE TABLE t1
- TRUNCATE TABLE t1 --
until this patch t1 or t2 could be evaluated at the first execution of
prepared statement.
CURRENT_DATABASE() still works OK and is evaluated at every execution
of prepared statement.
Note, that in stored routines this is not an issue as the default
database is the database of the stored procedure and "use" statement
is prohibited in stored routines.
This patch makes obsolete the use of check_db_used (it was never used in the
old code too) and all other places that check for table->db and assign it
from THD::db if it's NULL, except the parser.
How this patch was created: THD::{db,db_length} were replaced with a
LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
manually checked and:
- if the place uses thd->db by pointer, it was fixed to make a deep copy
- if a place compared two db pointers, it was fixed to compare them by value
(via strcmp/my_strcasecmp, whatever was approproate)
Then this intermediate patch was used to write a smaller patch that does the
same thing but without a rename.
TODO in 5.1:
- remove check_db_used
- deploy THD::set_db in mysql_change_db
See also comments to individual files.
2006-06-26 22:47:52 +02:00
|
|
|
LEX_STRING db;
|
2007-04-03 13:13:27 +02:00
|
|
|
if (check_routine_name(&$1))
|
2006-01-11 15:11:05 +01:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-11 15:11:05 +01:00
|
|
|
}
|
2007-07-05 09:34:04 +02:00
|
|
|
if (lex->copy_db_to(&db.str, &db.length))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2007-03-27 18:31:44 +02:00
|
|
|
$$= new sp_name(db, $1, false);
|
A fix and a test case for
Bug#19022 "Memory bug when switching db during trigger execution"
Bug#17199 "Problem when view calls function from another database."
Bug#18444 "Fully qualified stored function names don't work correctly in
SELECT statements"
Documentation note: this patch introduces a change in behaviour of prepared
statements.
This patch adds a few new invariants with regard to how THD::db should
be used. These invariants should be preserved in future:
- one should never refer to THD::db by pointer and always make a deep copy
(strmake, strdup)
- one should never compare two databases by pointer, but use strncmp or
my_strncasecmp
- TABLE_LIST object table->db should be always initialized in the parser or
by creator of the object.
For prepared statements it means that if the current database is changed
after a statement is prepared, the database that was current at prepare
remains active. This also means that you can not prepare a statement that
implicitly refers to the current database if the latter is not set.
This is not documented, and therefore needs documentation. This is NOT a
change in behavior for almost all SQL statements except:
- ALTER TABLE t1 RENAME t2
- OPTIMIZE TABLE t1
- ANALYZE TABLE t1
- TRUNCATE TABLE t1 --
until this patch t1 or t2 could be evaluated at the first execution of
prepared statement.
CURRENT_DATABASE() still works OK and is evaluated at every execution
of prepared statement.
Note, that in stored routines this is not an issue as the default
database is the database of the stored procedure and "use" statement
is prohibited in stored routines.
This patch makes obsolete the use of check_db_used (it was never used in the
old code too) and all other places that check for table->db and assign it
from THD::db if it's NULL, except the parser.
How this patch was created: THD::{db,db_length} were replaced with a
LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
manually checked and:
- if the place uses thd->db by pointer, it was fixed to make a deep copy
- if a place compared two db pointers, it was fixed to compare them by value
(via strcmp/my_strcasecmp, whatever was approproate)
Then this intermediate patch was used to write a smaller patch that does the
same thing but without a rename.
TODO in 5.1:
- remove check_db_used
- deploy THD::set_db in mysql_change_db
See also comments to individual files.
2006-06-26 22:47:52 +02:00
|
|
|
if ($$)
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
$$->init_qname(thd);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
create_function_tail:
|
2005-11-06 13:13:06 +01:00
|
|
|
RETURNS_SYM udf_type SONAME_SYM TEXT_STRING_sys
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
Bug#18239 (Possible to overload internal functions with stored functions)
Bug#21025 (misleading error message when creating functions named 'x', or 'y')
Bug#22619 (Spaces considered harmful)
This change contains a fix to report warnings or errors, and multiple tests
cases.
Before this fix, name collisions between:
- Native functions
- User Defined Functions
- Stored Functions
were not systematically reported, leading to confusing behavior.
I) Native / User Defined Function
Before this fix, is was possible to create a UDF named "foo", with the same
name as a native function "foo", but it was impossible to invoke the UDF,
since the syntax "foo()" always refer to the native function.
After this fix, creating a UDF fails with an error if there is a name
collision with a native function.
II) Native / Stored Function
Before this fix, is was possible to create a SF named "db.foo", with the same
name as a native function "foo", but this was confusing since the syntax
"foo()" would refer to the native function. To refer to the Stored Function,
the user had to use the "db.foo()" syntax.
After this fix, creating a Stored Function reports a warning if there is a
name collision with a native function.
III) User Defined Function / Stored Function
Before this fix, creating a User Defined Function "foo" and a Stored Function
"db.foo" are mutually exclusive operations. Whenever the second function is
created, an error is reported. However, the test suite did not cover this
behavior.
After this fix, the behavior is unchanged, and is now covered by test cases.
Note that the code change in this patch depends on the fix for Bug 21114.
2006-11-15 03:34:16 +01:00
|
|
|
THD *thd= YYTHD;
|
2007-01-27 02:46:45 +01:00
|
|
|
LEX *lex= thd->lex;
|
2006-07-31 21:01:43 +02:00
|
|
|
if (lex->definer != NULL)
|
|
|
|
{
|
|
|
|
/*
|
2006-08-15 00:50:26 +02:00
|
|
|
DEFINER is a concept meaningful when interpreting SQL code.
|
|
|
|
UDF functions are compiled.
|
|
|
|
Using DEFINER with UDF has therefore no semantic,
|
|
|
|
and is considered a parsing error.
|
2006-07-31 21:01:43 +02:00
|
|
|
*/
|
|
|
|
my_error(ER_WRONG_USAGE, MYF(0), "SONAME", "DEFINER");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-07-31 21:01:43 +02:00
|
|
|
}
|
Bug#18239 (Possible to overload internal functions with stored functions)
Bug#21025 (misleading error message when creating functions named 'x', or 'y')
Bug#22619 (Spaces considered harmful)
This change contains a fix to report warnings or errors, and multiple tests
cases.
Before this fix, name collisions between:
- Native functions
- User Defined Functions
- Stored Functions
were not systematically reported, leading to confusing behavior.
I) Native / User Defined Function
Before this fix, is was possible to create a UDF named "foo", with the same
name as a native function "foo", but it was impossible to invoke the UDF,
since the syntax "foo()" always refer to the native function.
After this fix, creating a UDF fails with an error if there is a name
collision with a native function.
II) Native / Stored Function
Before this fix, is was possible to create a SF named "db.foo", with the same
name as a native function "foo", but this was confusing since the syntax
"foo()" would refer to the native function. To refer to the Stored Function,
the user had to use the "db.foo()" syntax.
After this fix, creating a Stored Function reports a warning if there is a
name collision with a native function.
III) User Defined Function / Stored Function
Before this fix, creating a User Defined Function "foo" and a Stored Function
"db.foo" are mutually exclusive operations. Whenever the second function is
created, an error is reported. However, the test suite did not cover this
behavior.
After this fix, the behavior is unchanged, and is now covered by test cases.
Note that the code change in this patch depends on the fix for Bug 21114.
2006-11-15 03:34:16 +01:00
|
|
|
if (is_native_function(thd, & lex->spname->m_name))
|
|
|
|
{
|
|
|
|
my_error(ER_NATIVE_FCT_NAME_COLLISION, MYF(0),
|
|
|
|
lex->spname->m_name.str);
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
Bug#18239 (Possible to overload internal functions with stored functions)
Bug#21025 (misleading error message when creating functions named 'x', or 'y')
Bug#22619 (Spaces considered harmful)
This change contains a fix to report warnings or errors, and multiple tests
cases.
Before this fix, name collisions between:
- Native functions
- User Defined Functions
- Stored Functions
were not systematically reported, leading to confusing behavior.
I) Native / User Defined Function
Before this fix, is was possible to create a UDF named "foo", with the same
name as a native function "foo", but it was impossible to invoke the UDF,
since the syntax "foo()" always refer to the native function.
After this fix, creating a UDF fails with an error if there is a name
collision with a native function.
II) Native / Stored Function
Before this fix, is was possible to create a SF named "db.foo", with the same
name as a native function "foo", but this was confusing since the syntax
"foo()" would refer to the native function. To refer to the Stored Function,
the user had to use the "db.foo()" syntax.
After this fix, creating a Stored Function reports a warning if there is a
name collision with a native function.
III) User Defined Function / Stored Function
Before this fix, creating a User Defined Function "foo" and a Stored Function
"db.foo" are mutually exclusive operations. Whenever the second function is
created, an error is reported. However, the test suite did not cover this
behavior.
After this fix, the behavior is unchanged, and is now covered by test cases.
Note that the code change in this patch depends on the fix for Bug 21114.
2006-11-15 03:34:16 +01:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->sql_command = SQLCOM_CREATE_FUNCTION;
|
|
|
|
lex->udf.name = lex->spname->m_name;
|
|
|
|
lex->udf.returns=(Item_result) $2;
|
|
|
|
lex->udf.dl=$4.str;
|
|
|
|
}
|
|
|
|
| '('
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_head *sp;
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
const char* tmp_param_begin;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2006-02-09 13:00:32 +01:00
|
|
|
/*
|
|
|
|
First check if AGGREGATE was used, in that case it's a
|
|
|
|
syntax error.
|
|
|
|
*/
|
|
|
|
if (lex->udf.type == UDFTYPE_AGGREGATE)
|
|
|
|
{
|
|
|
|
my_error(ER_SP_NO_AGGREGATE, MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-02-09 13:00:32 +01:00
|
|
|
}
|
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
if (lex->sphead)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_SP_NO_RECURSIVE_CREATE, MYF(0), "FUNCTION");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
/* Order is important here: new - reset - init */
|
|
|
|
sp= new sp_head();
|
2007-04-26 05:38:12 +02:00
|
|
|
sp->reset_thd_mem_root(thd);
|
2004-11-12 04:01:46 +01:00
|
|
|
sp->init(lex);
|
2007-04-26 05:38:12 +02:00
|
|
|
sp->init_sp_name(thd, lex->spname);
|
2004-11-12 04:01:46 +01:00
|
|
|
|
|
|
|
sp->m_type= TYPE_ENUM_FUNCTION;
|
|
|
|
lex->sphead= sp;
|
|
|
|
/*
|
2006-08-17 14:22:59 +02:00
|
|
|
We have to turn off CLIENT_MULTI_QUERIES while parsing a
|
|
|
|
stored procedure, otherwise yylex will chop it into pieces
|
|
|
|
at each ';'.
|
|
|
|
*/
|
2007-04-26 05:38:12 +02:00
|
|
|
$<ulong_num>$= thd->client_capabilities & CLIENT_MULTI_QUERIES;
|
|
|
|
thd->client_capabilities &= ~CLIENT_MULTI_QUERIES;
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
|
|
|
|
tmp_param_begin= lip->get_cpp_tok_start();
|
|
|
|
tmp_param_begin++;
|
|
|
|
lex->sphead->m_param_begin= tmp_param_begin;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
sp_fdparam_list ')'
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
lex->sphead->m_param_end= lip->get_cpp_tok_start();
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
RETURNS_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2005-03-04 22:14:35 +01:00
|
|
|
lex->charset= NULL;
|
|
|
|
lex->length= lex->dec= NULL;
|
|
|
|
lex->interval_list.empty();
|
|
|
|
lex->type= 0;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
type
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
2006-08-09 17:07:59 +02:00
|
|
|
/*
|
|
|
|
This was disabled in 5.1.12. See bug #20701
|
|
|
|
When collation support in SP is implemented, then this test
|
|
|
|
should be removed.
|
|
|
|
*/
|
2006-12-02 02:26:52 +01:00
|
|
|
if (($8 == MYSQL_TYPE_STRING || $8 == MYSQL_TYPE_VARCHAR)
|
2006-08-09 17:07:59 +02:00
|
|
|
&& (lex->type & BINCMP_FLAG))
|
|
|
|
{
|
|
|
|
my_error(ER_NOT_SUPPORTED_YET, MYF(0), "return value collation");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-08-09 17:07:59 +02:00
|
|
|
}
|
2005-03-04 22:14:35 +01:00
|
|
|
|
2005-12-07 15:01:17 +01:00
|
|
|
if (sp->fill_field_definition(YYTHD, lex,
|
|
|
|
(enum enum_field_types) $8,
|
|
|
|
&sp->m_return_field_def))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
|
|
|
bzero((char *)&lex->sp_chistics, sizeof(st_sp_chistics));
|
|
|
|
}
|
|
|
|
sp_c_chistics
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
|
|
|
lex->sphead->m_chistics= &lex->sp_chistics;
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
lex->sphead->set_body_start(thd, lip->get_cpp_tok_start());
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
sp_proc_stmt
|
|
|
|
{
|
Bug#18239 (Possible to overload internal functions with stored functions)
Bug#21025 (misleading error message when creating functions named 'x', or 'y')
Bug#22619 (Spaces considered harmful)
This change contains a fix to report warnings or errors, and multiple tests
cases.
Before this fix, name collisions between:
- Native functions
- User Defined Functions
- Stored Functions
were not systematically reported, leading to confusing behavior.
I) Native / User Defined Function
Before this fix, is was possible to create a UDF named "foo", with the same
name as a native function "foo", but it was impossible to invoke the UDF,
since the syntax "foo()" always refer to the native function.
After this fix, creating a UDF fails with an error if there is a name
collision with a native function.
II) Native / Stored Function
Before this fix, is was possible to create a SF named "db.foo", with the same
name as a native function "foo", but this was confusing since the syntax
"foo()" would refer to the native function. To refer to the Stored Function,
the user had to use the "db.foo()" syntax.
After this fix, creating a Stored Function reports a warning if there is a
name collision with a native function.
III) User Defined Function / Stored Function
Before this fix, creating a User Defined Function "foo" and a Stored Function
"db.foo" are mutually exclusive operations. Whenever the second function is
created, an error is reported. However, the test suite did not cover this
behavior.
After this fix, the behavior is unchanged, and is now covered by test cases.
Note that the code change in this patch depends on the fix for Bug 21114.
2006-11-15 03:34:16 +01:00
|
|
|
THD *thd= YYTHD;
|
2007-01-27 02:46:45 +01:00
|
|
|
LEX *lex= thd->lex;
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
if (sp->is_not_allowed_in_function("function"))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->sql_command= SQLCOM_CREATE_SPFUNCTION;
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
sp->set_stmt_end(thd);
|
2005-11-25 17:09:26 +01:00
|
|
|
if (!(sp->m_flags & sp_head::HAS_RETURN))
|
|
|
|
{
|
|
|
|
my_error(ER_SP_NORETURN, MYF(0), sp->m_qname.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-11-25 17:09:26 +01:00
|
|
|
}
|
Bug#18239 (Possible to overload internal functions with stored functions)
Bug#21025 (misleading error message when creating functions named 'x', or 'y')
Bug#22619 (Spaces considered harmful)
This change contains a fix to report warnings or errors, and multiple tests
cases.
Before this fix, name collisions between:
- Native functions
- User Defined Functions
- Stored Functions
were not systematically reported, leading to confusing behavior.
I) Native / User Defined Function
Before this fix, is was possible to create a UDF named "foo", with the same
name as a native function "foo", but it was impossible to invoke the UDF,
since the syntax "foo()" always refer to the native function.
After this fix, creating a UDF fails with an error if there is a name
collision with a native function.
II) Native / Stored Function
Before this fix, is was possible to create a SF named "db.foo", with the same
name as a native function "foo", but this was confusing since the syntax
"foo()" would refer to the native function. To refer to the Stored Function,
the user had to use the "db.foo()" syntax.
After this fix, creating a Stored Function reports a warning if there is a
name collision with a native function.
III) User Defined Function / Stored Function
Before this fix, creating a User Defined Function "foo" and a Stored Function
"db.foo" are mutually exclusive operations. Whenever the second function is
created, an error is reported. However, the test suite did not cover this
behavior.
After this fix, the behavior is unchanged, and is now covered by test cases.
Note that the code change in this patch depends on the fix for Bug 21114.
2006-11-15 03:34:16 +01:00
|
|
|
if (is_native_function(thd, & sp->m_name))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
This warning will be printed when
|
|
|
|
[1] A client query is parsed,
|
|
|
|
[2] A stored function is loaded by db_load_routine.
|
|
|
|
Printing the warning for [2] is intentional, to cover the
|
|
|
|
following scenario:
|
|
|
|
- A user define a SF 'foo' using MySQL 5.N
|
|
|
|
- An application uses select foo(), and works.
|
|
|
|
- MySQL 5.{N+1} defines a new native function 'foo', as
|
|
|
|
part of a new feature.
|
|
|
|
- MySQL 5.{N+1} documentation is updated, and should mention
|
|
|
|
that there is a potential incompatible change in case of
|
|
|
|
existing stored function named 'foo'.
|
|
|
|
- The user deploys 5.{N+1}. At this point, 'select foo()'
|
|
|
|
means something different, and the user code is most likely
|
|
|
|
broken (it's only safe if the code is 'select db.foo()').
|
|
|
|
With a warning printed when the SF is loaded (which has to occur
|
|
|
|
before the call), the warning will provide a hint explaining
|
|
|
|
the root cause of a later failure of 'select foo()'.
|
|
|
|
With no warning printed, the user code will fail with no
|
|
|
|
apparent reason.
|
|
|
|
Printing a warning each time db_load_routine is executed for
|
|
|
|
an ambiguous function is annoying, since that can happen a lot,
|
|
|
|
but in practice should not happen unless there *are* name
|
|
|
|
collisions.
|
|
|
|
If a collision exists, it should not be silenced but fixed.
|
|
|
|
*/
|
|
|
|
push_warning_printf(thd,
|
|
|
|
MYSQL_ERROR::WARN_LEVEL_NOTE,
|
|
|
|
ER_NATIVE_FCT_NAME_COLLISION,
|
|
|
|
ER(ER_NATIVE_FCT_NAME_COLLISION),
|
|
|
|
sp->m_name.str);
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
/* Restore flag if it was cleared above */
|
Bug#18239 (Possible to overload internal functions with stored functions)
Bug#21025 (misleading error message when creating functions named 'x', or 'y')
Bug#22619 (Spaces considered harmful)
This change contains a fix to report warnings or errors, and multiple tests
cases.
Before this fix, name collisions between:
- Native functions
- User Defined Functions
- Stored Functions
were not systematically reported, leading to confusing behavior.
I) Native / User Defined Function
Before this fix, is was possible to create a UDF named "foo", with the same
name as a native function "foo", but it was impossible to invoke the UDF,
since the syntax "foo()" always refer to the native function.
After this fix, creating a UDF fails with an error if there is a name
collision with a native function.
II) Native / Stored Function
Before this fix, is was possible to create a SF named "db.foo", with the same
name as a native function "foo", but this was confusing since the syntax
"foo()" would refer to the native function. To refer to the Stored Function,
the user had to use the "db.foo()" syntax.
After this fix, creating a Stored Function reports a warning if there is a
name collision with a native function.
III) User Defined Function / Stored Function
Before this fix, creating a User Defined Function "foo" and a Stored Function
"db.foo" are mutually exclusive operations. Whenever the second function is
created, an error is reported. However, the test suite did not cover this
behavior.
After this fix, the behavior is unchanged, and is now covered by test cases.
Note that the code change in this patch depends on the fix for Bug 21114.
2006-11-15 03:34:16 +01:00
|
|
|
thd->client_capabilities |= $<ulong_num>2;
|
|
|
|
sp->restore_thd_mem_root(thd);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_a_chistics:
|
|
|
|
/* Empty */ {}
|
|
|
|
| sp_a_chistics sp_chistic {}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_c_chistics:
|
|
|
|
/* Empty */ {}
|
|
|
|
| sp_c_chistics sp_c_chistic {}
|
|
|
|
;
|
|
|
|
|
|
|
|
/* Characteristics for both create and alter */
|
|
|
|
sp_chistic:
|
|
|
|
COMMENT_SYM TEXT_STRING_sys
|
|
|
|
{ Lex->sp_chistics.comment= $2; }
|
|
|
|
| LANGUAGE_SYM SQL_SYM
|
|
|
|
{ /* Just parse it, we only have one language for now. */ }
|
|
|
|
| NO_SYM SQL_SYM
|
|
|
|
{ Lex->sp_chistics.daccess= SP_NO_SQL; }
|
|
|
|
| CONTAINS_SYM SQL_SYM
|
|
|
|
{ Lex->sp_chistics.daccess= SP_CONTAINS_SQL; }
|
|
|
|
| READS_SYM SQL_SYM DATA_SYM
|
|
|
|
{ Lex->sp_chistics.daccess= SP_READS_SQL_DATA; }
|
|
|
|
| MODIFIES_SYM SQL_SYM DATA_SYM
|
|
|
|
{ Lex->sp_chistics.daccess= SP_MODIFIES_SQL_DATA; }
|
|
|
|
| sp_suid
|
|
|
|
{ }
|
|
|
|
;
|
|
|
|
|
|
|
|
/* Create characteristics */
|
|
|
|
sp_c_chistic:
|
|
|
|
sp_chistic { }
|
|
|
|
| DETERMINISTIC_SYM { Lex->sp_chistics.detistic= TRUE; }
|
2004-11-17 16:49:10 +01:00
|
|
|
| not DETERMINISTIC_SYM { Lex->sp_chistics.detistic= FALSE; }
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_suid:
|
|
|
|
SQL_SYM SECURITY_SYM DEFINER_SYM
|
|
|
|
{
|
|
|
|
Lex->sp_chistics.suid= SP_IS_SUID;
|
|
|
|
}
|
|
|
|
| SQL_SYM SECURITY_SYM INVOKER_SYM
|
|
|
|
{
|
|
|
|
Lex->sp_chistics.suid= SP_IS_NOT_SUID;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
call:
|
|
|
|
CALL_SYM sp_name
|
|
|
|
{
|
|
|
|
LEX *lex = Lex;
|
|
|
|
|
|
|
|
lex->sql_command= SQLCOM_CALL;
|
|
|
|
lex->spname= $2;
|
|
|
|
lex->value_list.empty();
|
2005-07-09 19:51:59 +02:00
|
|
|
sp_add_used_routine(lex, YYTHD, $2, TYPE_ENUM_PROCEDURE);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
Bug#21462 (Stored procedures with no arguments require parenthesis)
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.
2006-10-09 18:59:02 +02:00
|
|
|
opt_sp_cparam_list {}
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
/* CALL parameters */
|
Bug#21462 (Stored procedures with no arguments require parenthesis)
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.
2006-10-09 18:59:02 +02:00
|
|
|
opt_sp_cparam_list:
|
2004-11-12 04:01:46 +01:00
|
|
|
/* Empty */
|
Bug#21462 (Stored procedures with no arguments require parenthesis)
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.
2006-10-09 18:59:02 +02:00
|
|
|
| '(' opt_sp_cparams ')'
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
|
|
|
|
Bug#21462 (Stored procedures with no arguments require parenthesis)
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.
2006-10-09 18:59:02 +02:00
|
|
|
opt_sp_cparams:
|
|
|
|
/* Empty */
|
|
|
|
| sp_cparams
|
|
|
|
;
|
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_cparams:
|
|
|
|
sp_cparams ',' expr
|
|
|
|
{
|
|
|
|
Lex->value_list.push_back($3);
|
|
|
|
}
|
|
|
|
| expr
|
|
|
|
{
|
|
|
|
Lex->value_list.push_back($1);
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
/* Stored FUNCTION parameter declaration list */
|
|
|
|
sp_fdparam_list:
|
|
|
|
/* Empty */
|
|
|
|
| sp_fdparams
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_fdparams:
|
|
|
|
sp_fdparams ',' sp_fdparam
|
|
|
|
| sp_fdparam
|
|
|
|
;
|
|
|
|
|
2005-12-07 15:01:17 +01:00
|
|
|
sp_init_param:
|
|
|
|
/* Empty */
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
|
|
|
|
lex->length= 0;
|
|
|
|
lex->dec= 0;
|
|
|
|
lex->type= 0;
|
|
|
|
|
|
|
|
lex->default_value= 0;
|
|
|
|
lex->on_update_value= 0;
|
|
|
|
|
|
|
|
lex->comment= null_lex_str;
|
|
|
|
lex->charset= NULL;
|
|
|
|
|
|
|
|
lex->interval_list.empty();
|
|
|
|
lex->uint_geom_type= 0;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_fdparam:
|
2005-12-07 15:01:17 +01:00
|
|
|
ident sp_init_param type
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_pcontext *spc= lex->spcont;
|
|
|
|
|
2006-04-07 16:53:15 +02:00
|
|
|
if (spc->find_variable(&$1, TRUE))
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_DUP_PARAM, MYF(0), $1.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2006-04-07 16:53:15 +02:00
|
|
|
sp_variable_t *spvar= spc->push_variable(&$1,
|
|
|
|
(enum enum_field_types)$3,
|
|
|
|
sp_param_in);
|
2005-12-07 15:01:17 +01:00
|
|
|
|
|
|
|
if (lex->sphead->fill_field_definition(YYTHD, lex,
|
|
|
|
(enum enum_field_types) $3,
|
2006-04-07 16:53:15 +02:00
|
|
|
&spvar->field_def))
|
2005-12-07 15:01:17 +01:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-12-07 15:01:17 +01:00
|
|
|
}
|
2006-04-07 16:53:15 +02:00
|
|
|
spvar->field_def.field_name= spvar->name.str;
|
|
|
|
spvar->field_def.pack_flag |= FIELDFLAG_MAYBE_NULL;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
/* Stored PROCEDURE parameter declaration list */
|
|
|
|
sp_pdparam_list:
|
|
|
|
/* Empty */
|
|
|
|
| sp_pdparams
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_pdparams:
|
|
|
|
sp_pdparams ',' sp_pdparam
|
|
|
|
| sp_pdparam
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_pdparam:
|
2005-12-07 15:01:17 +01:00
|
|
|
sp_opt_inout sp_init_param ident type
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_pcontext *spc= lex->spcont;
|
|
|
|
|
2006-04-07 16:53:15 +02:00
|
|
|
if (spc->find_variable(&$3, TRUE))
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2005-12-07 15:01:17 +01:00
|
|
|
my_error(ER_SP_DUP_PARAM, MYF(0), $3.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2006-04-07 16:53:15 +02:00
|
|
|
sp_variable_t *spvar= spc->push_variable(&$3,
|
|
|
|
(enum enum_field_types)$4,
|
|
|
|
(sp_param_mode_t)$1);
|
2005-12-07 15:01:17 +01:00
|
|
|
|
|
|
|
if (lex->sphead->fill_field_definition(YYTHD, lex,
|
|
|
|
(enum enum_field_types) $4,
|
2006-04-07 16:53:15 +02:00
|
|
|
&spvar->field_def))
|
2005-12-07 15:01:17 +01:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-12-07 15:01:17 +01:00
|
|
|
}
|
2006-04-07 16:53:15 +02:00
|
|
|
spvar->field_def.field_name= spvar->name.str;
|
|
|
|
spvar->field_def.pack_flag |= FIELDFLAG_MAYBE_NULL;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_opt_inout:
|
|
|
|
/* Empty */ { $$= sp_param_in; }
|
|
|
|
| IN_SYM { $$= sp_param_in; }
|
|
|
|
| OUT_SYM { $$= sp_param_out; }
|
|
|
|
| INOUT_SYM { $$= sp_param_inout; }
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_proc_stmts:
|
|
|
|
/* Empty */ {}
|
2005-03-04 14:35:28 +01:00
|
|
|
| sp_proc_stmts sp_proc_stmt ';'
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_proc_stmts1:
|
|
|
|
sp_proc_stmt ';' {}
|
2005-03-04 14:35:28 +01:00
|
|
|
| sp_proc_stmts1 sp_proc_stmt ';'
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_decls:
|
|
|
|
/* Empty */
|
|
|
|
{
|
|
|
|
$$.vars= $$.conds= $$.hndlrs= $$.curs= 0;
|
|
|
|
}
|
|
|
|
| sp_decls sp_decl ';'
|
|
|
|
{
|
|
|
|
/* We check for declarations out of (standard) order this way
|
|
|
|
because letting the grammar rules reflect it caused tricky
|
|
|
|
shift/reduce conflicts with the wrong result. (And we get
|
|
|
|
better error handling this way.) */
|
|
|
|
if (($2.vars || $2.conds) && ($1.curs || $1.hndlrs))
|
|
|
|
{ /* Variable or condition following cursor or handler */
|
2004-11-12 13:34:00 +01:00
|
|
|
my_message(ER_SP_VARCOND_AFTER_CURSHNDLR,
|
|
|
|
ER(ER_SP_VARCOND_AFTER_CURSHNDLR), MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
if ($2.curs && $1.hndlrs)
|
|
|
|
{ /* Cursor following handler */
|
2004-11-12 13:34:00 +01:00
|
|
|
my_message(ER_SP_CURSOR_AFTER_HANDLER,
|
|
|
|
ER(ER_SP_CURSOR_AFTER_HANDLER), MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
$$.vars= $1.vars + $2.vars;
|
|
|
|
$$.conds= $1.conds + $2.conds;
|
|
|
|
$$.hndlrs= $1.hndlrs + $2.hndlrs;
|
|
|
|
$$.curs= $1.curs + $2.curs;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_decl:
|
2005-12-07 15:01:17 +01:00
|
|
|
DECLARE_SYM sp_decl_idents
|
2005-11-01 14:58:52 +01:00
|
|
|
{
|
2005-12-02 14:30:42 +01:00
|
|
|
LEX *lex= Lex;
|
2005-11-01 14:58:52 +01:00
|
|
|
|
2005-12-02 14:30:42 +01:00
|
|
|
lex->sphead->reset_lex(YYTHD);
|
|
|
|
lex->spcont->declare_var_boundary($2);
|
|
|
|
}
|
2005-12-07 15:01:17 +01:00
|
|
|
type
|
2005-03-04 14:35:28 +01:00
|
|
|
sp_opt_default
|
2005-09-13 12:50:21 +02:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2005-12-07 15:01:17 +01:00
|
|
|
sp_pcontext *pctx= lex->spcont;
|
2006-04-07 16:53:15 +02:00
|
|
|
uint num_vars= pctx->context_var_count();
|
2005-12-07 15:01:17 +01:00
|
|
|
enum enum_field_types var_type= (enum enum_field_types) $4;
|
|
|
|
Item *dflt_value_item= $5;
|
|
|
|
|
|
|
|
if (!dflt_value_item)
|
2005-09-13 12:50:21 +02:00
|
|
|
{
|
2005-12-07 15:01:17 +01:00
|
|
|
dflt_value_item= new Item_null();
|
|
|
|
/* QQ Set to the var_type with null_value? */
|
|
|
|
}
|
|
|
|
|
|
|
|
for (uint i = num_vars-$2 ; i < num_vars ; i++)
|
|
|
|
{
|
2006-04-07 16:53:15 +02:00
|
|
|
uint var_idx= pctx->var_context2runtime(i);
|
|
|
|
sp_variable_t *spvar= pctx->find_variable(var_idx);
|
2005-12-07 15:01:17 +01:00
|
|
|
|
2006-04-07 16:53:15 +02:00
|
|
|
if (!spvar)
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-12-07 15:01:17 +01:00
|
|
|
|
2006-04-07 16:53:15 +02:00
|
|
|
spvar->type= var_type;
|
|
|
|
spvar->dflt= dflt_value_item;
|
2005-12-07 15:01:17 +01:00
|
|
|
|
|
|
|
if (lex->sphead->fill_field_definition(YYTHD, lex, var_type,
|
2006-04-07 16:53:15 +02:00
|
|
|
&spvar->field_def))
|
2005-12-07 15:01:17 +01:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-12-07 15:01:17 +01:00
|
|
|
}
|
|
|
|
|
2006-04-07 16:53:15 +02:00
|
|
|
spvar->field_def.field_name= spvar->name.str;
|
|
|
|
spvar->field_def.pack_flag |= FIELDFLAG_MAYBE_NULL;
|
2005-12-07 15:01:17 +01:00
|
|
|
|
|
|
|
/* The last instruction is responsible for freeing LEX. */
|
|
|
|
|
|
|
|
lex->sphead->add_instr(
|
|
|
|
new sp_instr_set(lex->sphead->instructions(), pctx, var_idx,
|
|
|
|
dflt_value_item, var_type, lex,
|
|
|
|
(i == num_vars - 1)));
|
2005-09-13 12:50:21 +02:00
|
|
|
}
|
2005-12-07 15:01:17 +01:00
|
|
|
|
|
|
|
pctx->declare_var_boundary(0);
|
2005-03-04 14:35:28 +01:00
|
|
|
lex->sphead->restore_lex(YYTHD);
|
2005-12-07 15:01:17 +01:00
|
|
|
|
2005-09-13 12:50:21 +02:00
|
|
|
$$.vars= $2;
|
|
|
|
$$.conds= $$.hndlrs= $$.curs= 0;
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
| DECLARE_SYM ident CONDITION_SYM FOR_SYM sp_cond
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_pcontext *spc= lex->spcont;
|
|
|
|
|
|
|
|
if (spc->find_cond(&$2, TRUE))
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_DUP_COND, MYF(0), $2.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
YYTHD->lex->spcont->push_cond(&$2, $5);
|
|
|
|
$$.vars= $$.hndlrs= $$.curs= 0;
|
|
|
|
$$.conds= 1;
|
|
|
|
}
|
|
|
|
| DECLARE_SYM sp_handler_type HANDLER_SYM FOR_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
Bug#26503 (Illegal SQL exception handler code causes the server to crash)
Before this fix, the parser would accept illegal code in SQL exceptions
handlers, that later causes the runtime to crash when executing the code,
due to memory violations in the exception handler stack.
The root cause of the problem is instructions within an exception handler
that jumps to code located outside of the handler. This is illegal according
to the SQL 2003 standard, since labels located outside the handler are not
supposed to be visible (they are "out of scope"), so any instruction that
jumps to these labels, like ITERATE or LEAVE, should not parse.
The section of the standard that is relevant for this is :
SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003)
section 13.1 <compound statement>,
syntax rule 4
<quote>
The scope of the <beginning label> is CS excluding every <SQL schema
statement> contained in CS and excluding every
<local handler declaration list> contained in CS. <beginning label> shall
not be equivalent to any other <beginning label>s within that scope.
</quote>
With this fix, the C++ class sp_pcontext, which represent the "parsing
context" tree (a.k.a symbol table) of a stored procedure, has been changed
as follows:
- constructors have been cleaned up, so that only building a root node for
the tree is public; building nodes inside a tree is not public.
- a new member, m_label_scope, indicates if a given syntactic context
belongs to a DECLARE HANDLER block,
- label resolution, in the method find_label(), has been changed to
implement the restriction of scope regarding labels used in a compound
statement.
The actions in the parser, when parsing the body of a SQL exception handler,
have been changed as follows:
- the implementation of an exception handler (DECLARE HANDLER) now creates
explicitly a new sp_pcontext, to isolate the code inside the handler from
the containing compound statement context.
- registering exception handlers as a result occurs in the parent context,
see the rule sp_hcond_element
- the code in sp_hcond_list has been cleaned up, to avoid code duplication
In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h
have been removed, since they are unused and broken by design (as seen with
Bug 19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation), representing a stack in a single flag is not possible.
Tests in sp-error have been added to show that illegal constructs are now
rejected.
Tests in sp have been added for code coverage, to show that ITERATE or LEAVE
statements are legal when jumping to a label in scope, inside the body of
an exception handler.
2007-03-14 19:02:32 +01:00
|
|
|
|
|
|
|
lex->spcont= lex->spcont->push_context(LABEL_HANDLER_SCOPE);
|
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_pcontext *ctx= lex->spcont;
|
|
|
|
sp_instr_hpush_jump *i=
|
|
|
|
new sp_instr_hpush_jump(sp->instructions(), ctx, $2,
|
2006-04-07 16:53:15 +02:00
|
|
|
ctx->current_var_count());
|
2004-11-12 04:01:46 +01:00
|
|
|
|
|
|
|
sp->add_instr(i);
|
|
|
|
sp->push_backpatch(i, ctx->push_label((char *)"", 0));
|
|
|
|
}
|
|
|
|
sp_hcond_list sp_proc_stmt
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
sp_pcontext *ctx= lex->spcont;
|
|
|
|
sp_label_t *hlab= lex->spcont->pop_label(); /* After this hdlr */
|
|
|
|
sp_instr_hreturn *i;
|
|
|
|
|
|
|
|
if ($2 == SP_HANDLER_CONTINUE)
|
|
|
|
{
|
|
|
|
i= new sp_instr_hreturn(sp->instructions(), ctx,
|
2006-04-07 16:53:15 +02:00
|
|
|
ctx->current_var_count());
|
2004-11-12 04:01:46 +01:00
|
|
|
sp->add_instr(i);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{ /* EXIT or UNDO handler, just jump to the end of the block */
|
|
|
|
i= new sp_instr_hreturn(sp->instructions(), ctx, 0);
|
|
|
|
|
|
|
|
sp->add_instr(i);
|
|
|
|
sp->push_backpatch(i, lex->spcont->last_label()); /* Block end */
|
|
|
|
}
|
|
|
|
lex->sphead->backpatch(hlab);
|
Bug#26503 (Illegal SQL exception handler code causes the server to crash)
Before this fix, the parser would accept illegal code in SQL exceptions
handlers, that later causes the runtime to crash when executing the code,
due to memory violations in the exception handler stack.
The root cause of the problem is instructions within an exception handler
that jumps to code located outside of the handler. This is illegal according
to the SQL 2003 standard, since labels located outside the handler are not
supposed to be visible (they are "out of scope"), so any instruction that
jumps to these labels, like ITERATE or LEAVE, should not parse.
The section of the standard that is relevant for this is :
SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003)
section 13.1 <compound statement>,
syntax rule 4
<quote>
The scope of the <beginning label> is CS excluding every <SQL schema
statement> contained in CS and excluding every
<local handler declaration list> contained in CS. <beginning label> shall
not be equivalent to any other <beginning label>s within that scope.
</quote>
With this fix, the C++ class sp_pcontext, which represent the "parsing
context" tree (a.k.a symbol table) of a stored procedure, has been changed
as follows:
- constructors have been cleaned up, so that only building a root node for
the tree is public; building nodes inside a tree is not public.
- a new member, m_label_scope, indicates if a given syntactic context
belongs to a DECLARE HANDLER block,
- label resolution, in the method find_label(), has been changed to
implement the restriction of scope regarding labels used in a compound
statement.
The actions in the parser, when parsing the body of a SQL exception handler,
have been changed as follows:
- the implementation of an exception handler (DECLARE HANDLER) now creates
explicitly a new sp_pcontext, to isolate the code inside the handler from
the containing compound statement context.
- registering exception handlers as a result occurs in the parent context,
see the rule sp_hcond_element
- the code in sp_hcond_list has been cleaned up, to avoid code duplication
In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h
have been removed, since they are unused and broken by design (as seen with
Bug 19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation), representing a stack in a single flag is not possible.
Tests in sp-error have been added to show that illegal constructs are now
rejected.
Tests in sp have been added for code coverage, to show that ITERATE or LEAVE
statements are legal when jumping to a label in scope, inside the body of
an exception handler.
2007-03-14 19:02:32 +01:00
|
|
|
|
|
|
|
lex->spcont= ctx->pop_context();
|
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
$$.vars= $$.conds= $$.curs= 0;
|
|
|
|
$$.hndlrs= $6;
|
Bug#26503 (Illegal SQL exception handler code causes the server to crash)
Before this fix, the parser would accept illegal code in SQL exceptions
handlers, that later causes the runtime to crash when executing the code,
due to memory violations in the exception handler stack.
The root cause of the problem is instructions within an exception handler
that jumps to code located outside of the handler. This is illegal according
to the SQL 2003 standard, since labels located outside the handler are not
supposed to be visible (they are "out of scope"), so any instruction that
jumps to these labels, like ITERATE or LEAVE, should not parse.
The section of the standard that is relevant for this is :
SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003)
section 13.1 <compound statement>,
syntax rule 4
<quote>
The scope of the <beginning label> is CS excluding every <SQL schema
statement> contained in CS and excluding every
<local handler declaration list> contained in CS. <beginning label> shall
not be equivalent to any other <beginning label>s within that scope.
</quote>
With this fix, the C++ class sp_pcontext, which represent the "parsing
context" tree (a.k.a symbol table) of a stored procedure, has been changed
as follows:
- constructors have been cleaned up, so that only building a root node for
the tree is public; building nodes inside a tree is not public.
- a new member, m_label_scope, indicates if a given syntactic context
belongs to a DECLARE HANDLER block,
- label resolution, in the method find_label(), has been changed to
implement the restriction of scope regarding labels used in a compound
statement.
The actions in the parser, when parsing the body of a SQL exception handler,
have been changed as follows:
- the implementation of an exception handler (DECLARE HANDLER) now creates
explicitly a new sp_pcontext, to isolate the code inside the handler from
the containing compound statement context.
- registering exception handlers as a result occurs in the parent context,
see the rule sp_hcond_element
- the code in sp_hcond_list has been cleaned up, to avoid code duplication
In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h
have been removed, since they are unused and broken by design (as seen with
Bug 19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation), representing a stack in a single flag is not possible.
Tests in sp-error have been added to show that illegal constructs are now
rejected.
Tests in sp have been added for code coverage, to show that ITERATE or LEAVE
statements are legal when jumping to a label in scope, inside the body of
an exception handler.
2007-03-14 19:02:32 +01:00
|
|
|
lex->spcont->add_handlers($6);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
| DECLARE_SYM ident CURSOR_SYM FOR_SYM sp_cursor_stmt
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
sp_pcontext *ctx= lex->spcont;
|
|
|
|
uint offp;
|
|
|
|
sp_instr_cpush *i;
|
|
|
|
|
|
|
|
if (ctx->find_cursor(&$2, &offp, TRUE))
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_DUP_CURS, MYF(0), $2.str);
|
2004-11-12 04:01:46 +01:00
|
|
|
delete $5;
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2005-11-17 11:11:48 +01:00
|
|
|
i= new sp_instr_cpush(sp->instructions(), ctx, $5,
|
2006-04-07 16:53:15 +02:00
|
|
|
ctx->current_cursor_count());
|
2004-11-12 04:01:46 +01:00
|
|
|
sp->add_instr(i);
|
|
|
|
ctx->push_cursor(&$2);
|
|
|
|
$$.vars= $$.conds= $$.hndlrs= 0;
|
|
|
|
$$.curs= 1;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_cursor_stmt:
|
|
|
|
{
|
|
|
|
Lex->sphead->reset_lex(YYTHD);
|
|
|
|
|
2006-06-20 12:20:32 +02:00
|
|
|
/*
|
|
|
|
We use statement here just be able to get a better
|
|
|
|
error message. Using 'select' works too, but will then
|
|
|
|
result in a generic "syntax error" if a non-select
|
|
|
|
statement is given.
|
|
|
|
*/
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
statement
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
|
2006-06-20 12:20:32 +02:00
|
|
|
if (lex->sql_command != SQLCOM_SELECT &&
|
|
|
|
!(sql_command_flags[lex->sql_command] & CF_STATUS_COMMAND))
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2004-11-12 13:34:00 +01:00
|
|
|
my_message(ER_SP_BAD_CURSOR_QUERY, ER(ER_SP_BAD_CURSOR_QUERY),
|
|
|
|
MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
if (lex->result)
|
|
|
|
{
|
2004-11-12 13:34:00 +01:00
|
|
|
my_message(ER_SP_BAD_CURSOR_SELECT, ER(ER_SP_BAD_CURSOR_SELECT),
|
|
|
|
MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
lex->sp_lex_in_use= TRUE;
|
|
|
|
$$= lex;
|
|
|
|
lex->sphead->restore_lex(YYTHD);
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_handler_type:
|
|
|
|
EXIT_SYM { $$= SP_HANDLER_EXIT; }
|
|
|
|
| CONTINUE_SYM { $$= SP_HANDLER_CONTINUE; }
|
|
|
|
/* | UNDO_SYM { QQ No yet } */
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_hcond_list:
|
Bug#26503 (Illegal SQL exception handler code causes the server to crash)
Before this fix, the parser would accept illegal code in SQL exceptions
handlers, that later causes the runtime to crash when executing the code,
due to memory violations in the exception handler stack.
The root cause of the problem is instructions within an exception handler
that jumps to code located outside of the handler. This is illegal according
to the SQL 2003 standard, since labels located outside the handler are not
supposed to be visible (they are "out of scope"), so any instruction that
jumps to these labels, like ITERATE or LEAVE, should not parse.
The section of the standard that is relevant for this is :
SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003)
section 13.1 <compound statement>,
syntax rule 4
<quote>
The scope of the <beginning label> is CS excluding every <SQL schema
statement> contained in CS and excluding every
<local handler declaration list> contained in CS. <beginning label> shall
not be equivalent to any other <beginning label>s within that scope.
</quote>
With this fix, the C++ class sp_pcontext, which represent the "parsing
context" tree (a.k.a symbol table) of a stored procedure, has been changed
as follows:
- constructors have been cleaned up, so that only building a root node for
the tree is public; building nodes inside a tree is not public.
- a new member, m_label_scope, indicates if a given syntactic context
belongs to a DECLARE HANDLER block,
- label resolution, in the method find_label(), has been changed to
implement the restriction of scope regarding labels used in a compound
statement.
The actions in the parser, when parsing the body of a SQL exception handler,
have been changed as follows:
- the implementation of an exception handler (DECLARE HANDLER) now creates
explicitly a new sp_pcontext, to isolate the code inside the handler from
the containing compound statement context.
- registering exception handlers as a result occurs in the parent context,
see the rule sp_hcond_element
- the code in sp_hcond_list has been cleaned up, to avoid code duplication
In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h
have been removed, since they are unused and broken by design (as seen with
Bug 19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation), representing a stack in a single flag is not possible.
Tests in sp-error have been added to show that illegal constructs are now
rejected.
Tests in sp have been added for code coverage, to show that ITERATE or LEAVE
statements are legal when jumping to a label in scope, inside the body of
an exception handler.
2007-03-14 19:02:32 +01:00
|
|
|
sp_hcond_element
|
|
|
|
{ $$= 1; }
|
|
|
|
| sp_hcond_list ',' sp_hcond_element
|
|
|
|
{ $$+= 1; }
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_hcond_element:
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_hcond
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
Bug#26503 (Illegal SQL exception handler code causes the server to crash)
Before this fix, the parser would accept illegal code in SQL exceptions
handlers, that later causes the runtime to crash when executing the code,
due to memory violations in the exception handler stack.
The root cause of the problem is instructions within an exception handler
that jumps to code located outside of the handler. This is illegal according
to the SQL 2003 standard, since labels located outside the handler are not
supposed to be visible (they are "out of scope"), so any instruction that
jumps to these labels, like ITERATE or LEAVE, should not parse.
The section of the standard that is relevant for this is :
SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003)
section 13.1 <compound statement>,
syntax rule 4
<quote>
The scope of the <beginning label> is CS excluding every <SQL schema
statement> contained in CS and excluding every
<local handler declaration list> contained in CS. <beginning label> shall
not be equivalent to any other <beginning label>s within that scope.
</quote>
With this fix, the C++ class sp_pcontext, which represent the "parsing
context" tree (a.k.a symbol table) of a stored procedure, has been changed
as follows:
- constructors have been cleaned up, so that only building a root node for
the tree is public; building nodes inside a tree is not public.
- a new member, m_label_scope, indicates if a given syntactic context
belongs to a DECLARE HANDLER block,
- label resolution, in the method find_label(), has been changed to
implement the restriction of scope regarding labels used in a compound
statement.
The actions in the parser, when parsing the body of a SQL exception handler,
have been changed as follows:
- the implementation of an exception handler (DECLARE HANDLER) now creates
explicitly a new sp_pcontext, to isolate the code inside the handler from
the containing compound statement context.
- registering exception handlers as a result occurs in the parent context,
see the rule sp_hcond_element
- the code in sp_hcond_list has been cleaned up, to avoid code duplication
In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h
have been removed, since they are unused and broken by design (as seen with
Bug 19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation), representing a stack in a single flag is not possible.
Tests in sp-error have been added to show that illegal constructs are now
rejected.
Tests in sp have been added for code coverage, to show that ITERATE or LEAVE
statements are legal when jumping to a label in scope, inside the body of
an exception handler.
2007-03-14 19:02:32 +01:00
|
|
|
sp_pcontext *ctx= lex->spcont->parent_context();
|
2005-04-08 19:58:04 +02:00
|
|
|
|
|
|
|
if (ctx->find_handler($1))
|
|
|
|
{
|
|
|
|
my_message(ER_SP_DUP_HANDLER, ER(ER_SP_DUP_HANDLER), MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-04-08 19:58:04 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
sp_instr_hpush_jump *i=
|
|
|
|
(sp_instr_hpush_jump *)sp->last_instruction();
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2005-04-08 19:58:04 +02:00
|
|
|
i->add_condition($1);
|
|
|
|
ctx->push_handler($1);
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_cond:
|
2005-04-04 00:50:05 +02:00
|
|
|
ulong_num
|
2004-11-12 04:01:46 +01:00
|
|
|
{ /* mysql errno */
|
|
|
|
$$= (sp_cond_type_t *)YYTHD->alloc(sizeof(sp_cond_type_t));
|
|
|
|
$$->type= sp_cond_type_t::number;
|
|
|
|
$$->mysqlerr= $1;
|
|
|
|
}
|
|
|
|
| SQLSTATE_SYM opt_value TEXT_STRING_literal
|
|
|
|
{ /* SQLSTATE */
|
2005-02-28 18:07:06 +01:00
|
|
|
if (!sp_cond_check(&$3))
|
|
|
|
{
|
|
|
|
my_error(ER_SP_BAD_SQLSTATE, MYF(0), $3.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-02-28 18:07:06 +01:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
$$= (sp_cond_type_t *)YYTHD->alloc(sizeof(sp_cond_type_t));
|
|
|
|
$$->type= sp_cond_type_t::state;
|
2005-02-28 18:07:06 +01:00
|
|
|
memcpy($$->sqlstate, $3.str, 5);
|
|
|
|
$$->sqlstate[5]= '\0';
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_value:
|
|
|
|
/* Empty */ {}
|
|
|
|
| VALUE_SYM {}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_hcond:
|
|
|
|
sp_cond
|
|
|
|
{
|
|
|
|
$$= $1;
|
|
|
|
}
|
|
|
|
| ident /* CONDITION name */
|
|
|
|
{
|
|
|
|
$$= Lex->spcont->find_cond(&$1);
|
|
|
|
if ($$ == NULL)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_COND_MISMATCH, MYF(0), $1.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
| SQLWARNING_SYM /* SQLSTATEs 01??? */
|
|
|
|
{
|
|
|
|
$$= (sp_cond_type_t *)YYTHD->alloc(sizeof(sp_cond_type_t));
|
|
|
|
$$->type= sp_cond_type_t::warning;
|
|
|
|
}
|
2004-11-17 16:49:10 +01:00
|
|
|
| not FOUND_SYM /* SQLSTATEs 02??? */
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
$$= (sp_cond_type_t *)YYTHD->alloc(sizeof(sp_cond_type_t));
|
|
|
|
$$->type= sp_cond_type_t::notfound;
|
|
|
|
}
|
|
|
|
| SQLEXCEPTION_SYM /* All other SQLSTATEs */
|
|
|
|
{
|
|
|
|
$$= (sp_cond_type_t *)YYTHD->alloc(sizeof(sp_cond_type_t));
|
|
|
|
$$->type= sp_cond_type_t::exception;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_decl_idents:
|
|
|
|
ident
|
|
|
|
{
|
2005-12-07 15:01:17 +01:00
|
|
|
/* NOTE: field definition is filled in sp_decl section. */
|
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_pcontext *spc= lex->spcont;
|
|
|
|
|
2006-04-07 16:53:15 +02:00
|
|
|
if (spc->find_variable(&$1, TRUE))
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_DUP_VAR, MYF(0), $1.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2006-04-07 16:53:15 +02:00
|
|
|
spc->push_variable(&$1, (enum_field_types)0, sp_param_in);
|
2004-11-12 04:01:46 +01:00
|
|
|
$$= 1;
|
|
|
|
}
|
|
|
|
| sp_decl_idents ',' ident
|
|
|
|
{
|
2005-12-07 15:01:17 +01:00
|
|
|
/* NOTE: field definition is filled in sp_decl section. */
|
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_pcontext *spc= lex->spcont;
|
|
|
|
|
2006-04-07 16:53:15 +02:00
|
|
|
if (spc->find_variable(&$3, TRUE))
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_DUP_VAR, MYF(0), $3.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2006-04-07 16:53:15 +02:00
|
|
|
spc->push_variable(&$3, (enum_field_types)0, sp_param_in);
|
2004-11-12 04:01:46 +01:00
|
|
|
$$= $1 + 1;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_opt_default:
|
|
|
|
/* Empty */ { $$ = NULL; }
|
|
|
|
| DEFAULT expr { $$ = $2; }
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_proc_stmt:
|
2005-12-02 13:07:02 +01:00
|
|
|
sp_proc_stmt_statement
|
|
|
|
| sp_proc_stmt_return
|
|
|
|
| sp_proc_stmt_if
|
2006-12-13 00:42:35 +01:00
|
|
|
| case_stmt_specification
|
2005-12-02 13:07:02 +01:00
|
|
|
| sp_labeled_control
|
|
|
|
| sp_proc_stmt_unlabeled
|
|
|
|
| sp_proc_stmt_leave
|
|
|
|
| sp_proc_stmt_iterate
|
|
|
|
| sp_proc_stmt_open
|
|
|
|
| sp_proc_stmt_fetch
|
|
|
|
| sp_proc_stmt_close
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_proc_stmt_if:
|
2006-02-02 10:03:35 +01:00
|
|
|
IF { Lex->sphead->new_cont_backpatch(NULL); }
|
|
|
|
sp_if END IF
|
|
|
|
{ Lex->sphead->do_cont_backpatch(); }
|
2005-12-02 13:07:02 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_proc_stmt_statement:
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2007-04-26 05:38:12 +02:00
|
|
|
lex->sphead->reset_lex(thd);
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
lex->sphead->m_tmp_query= lip->get_tok_start();
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
statement
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
sp->m_flags|= sp_get_flags_for_command(lex);
|
2004-11-12 04:01:46 +01:00
|
|
|
if (lex->sql_command == SQLCOM_CHANGE_DB)
|
|
|
|
{ /* "USE db" doesn't work in a procedure */
|
2005-08-10 08:31:32 +02:00
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "USE");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2005-03-04 14:35:28 +01:00
|
|
|
/*
|
|
|
|
Don't add an instruction for SET statements, since all
|
|
|
|
instructions for them were already added during processing
|
|
|
|
of "set" rule.
|
2004-11-12 04:01:46 +01:00
|
|
|
*/
|
2005-03-04 14:35:28 +01:00
|
|
|
DBUG_ASSERT(lex->sql_command != SQLCOM_SET_OPTION ||
|
|
|
|
lex->var_list.is_empty());
|
|
|
|
if (lex->sql_command != SQLCOM_SET_OPTION)
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2005-03-04 15:46:45 +01:00
|
|
|
sp_instr_stmt *i=new sp_instr_stmt(sp->instructions(),
|
|
|
|
lex->spcont, lex);
|
2005-02-08 20:52:50 +01:00
|
|
|
|
2006-07-07 19:24:54 +02:00
|
|
|
/*
|
|
|
|
Extract the query statement from the tokenizer. The
|
|
|
|
end is either lex->ptr, if there was no lookahead,
|
|
|
|
lex->tok_end otherwise.
|
|
|
|
*/
|
|
|
|
if (yychar == YYEMPTY)
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
i->m_query.length= lip->get_ptr() - sp->m_tmp_query;
|
2005-03-04 15:46:45 +01:00
|
|
|
else
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
i->m_query.length= lip->get_tok_end() - sp->m_tmp_query;
|
2007-04-26 05:38:12 +02:00
|
|
|
i->m_query.str= strmake_root(thd->mem_root,
|
2007-03-27 19:09:56 +02:00
|
|
|
sp->m_tmp_query,
|
2005-03-04 15:46:45 +01:00
|
|
|
i->m_query.length);
|
|
|
|
sp->add_instr(i);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2007-04-26 05:38:12 +02:00
|
|
|
sp->restore_lex(thd);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2005-12-02 13:07:02 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_proc_stmt_return:
|
|
|
|
RETURN_SYM
|
2005-03-04 14:35:28 +01:00
|
|
|
{ Lex->sphead->reset_lex(YYTHD); }
|
|
|
|
expr
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2005-03-04 14:35:28 +01:00
|
|
|
sp_head *sp= lex->sphead;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2006-01-28 10:50:16 +01:00
|
|
|
if (sp->m_type != TYPE_ENUM_FUNCTION)
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2004-11-12 13:34:00 +01:00
|
|
|
my_message(ER_SP_BADRETURN, ER(ER_SP_BADRETURN), MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
sp_instr_freturn *i;
|
|
|
|
|
2005-12-07 15:01:17 +01:00
|
|
|
i= new sp_instr_freturn(sp->instructions(), lex->spcont, $3,
|
|
|
|
sp->m_return_field_def.sql_type, lex);
|
2005-03-04 14:35:28 +01:00
|
|
|
sp->add_instr(i);
|
Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures".
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
2005-09-03 01:13:18 +02:00
|
|
|
sp->m_flags|= sp_head::HAS_RETURN;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2005-03-04 14:35:28 +01:00
|
|
|
sp->restore_lex(YYTHD);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2005-12-02 13:07:02 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_proc_stmt_unlabeled:
|
|
|
|
{ /* Unlabeled controls get a secret label. */
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
|
|
|
|
lex->spcont->push_label((char *)"", lex->sphead->instructions());
|
|
|
|
}
|
|
|
|
sp_unlabeled_control
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
|
|
|
|
lex->sphead->backpatch(lex->spcont->pop_label());
|
|
|
|
}
|
2005-12-02 13:07:02 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_proc_stmt_leave:
|
|
|
|
LEAVE_SYM label_ident
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp = lex->sphead;
|
|
|
|
sp_pcontext *ctx= lex->spcont;
|
|
|
|
sp_label_t *lab= ctx->find_label($2.str);
|
|
|
|
|
|
|
|
if (! lab)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_LILABEL_MISMATCH, MYF(0), "LEAVE", $2.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
sp_instr_jump *i;
|
2006-01-25 15:11:49 +01:00
|
|
|
uint ip= sp->instructions();
|
|
|
|
uint n;
|
|
|
|
|
2006-02-15 12:11:29 +01:00
|
|
|
n= ctx->diff_handlers(lab->ctx, TRUE); /* Exclusive the dest. */
|
2006-01-25 15:11:49 +01:00
|
|
|
if (n)
|
|
|
|
sp->add_instr(new sp_instr_hpop(ip++, ctx, n));
|
2006-02-15 12:11:29 +01:00
|
|
|
n= ctx->diff_cursors(lab->ctx, TRUE); /* Exclusive the dest. */
|
2006-01-25 15:11:49 +01:00
|
|
|
if (n)
|
|
|
|
sp->add_instr(new sp_instr_cpop(ip++, ctx, n));
|
2004-11-12 04:01:46 +01:00
|
|
|
i= new sp_instr_jump(ip, ctx);
|
|
|
|
sp->push_backpatch(i, lab); /* Jumping forward */
|
|
|
|
sp->add_instr(i);
|
|
|
|
}
|
|
|
|
}
|
2005-12-02 13:07:02 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_proc_stmt_iterate:
|
|
|
|
ITERATE_SYM label_ident
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
sp_pcontext *ctx= lex->spcont;
|
|
|
|
sp_label_t *lab= ctx->find_label($2.str);
|
|
|
|
|
|
|
|
if (! lab || lab->type != SP_LAB_ITER)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_LILABEL_MISMATCH, MYF(0), "ITERATE", $2.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
sp_instr_jump *i;
|
|
|
|
uint ip= sp->instructions();
|
|
|
|
uint n;
|
|
|
|
|
2006-02-15 12:11:29 +01:00
|
|
|
n= ctx->diff_handlers(lab->ctx, FALSE); /* Inclusive the dest. */
|
2004-11-12 04:01:46 +01:00
|
|
|
if (n)
|
|
|
|
sp->add_instr(new sp_instr_hpop(ip++, ctx, n));
|
2006-02-15 12:11:29 +01:00
|
|
|
n= ctx->diff_cursors(lab->ctx, FALSE); /* Inclusive the dest. */
|
2004-11-12 04:01:46 +01:00
|
|
|
if (n)
|
|
|
|
sp->add_instr(new sp_instr_cpop(ip++, ctx, n));
|
|
|
|
i= new sp_instr_jump(ip, ctx, lab->ip); /* Jump back */
|
|
|
|
sp->add_instr(i);
|
|
|
|
}
|
|
|
|
}
|
2005-12-02 13:07:02 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_proc_stmt_open:
|
|
|
|
OPEN_SYM ident
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
uint offset;
|
|
|
|
sp_instr_copen *i;
|
|
|
|
|
|
|
|
if (! lex->spcont->find_cursor(&$2, &offset))
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_CURSOR_MISMATCH, MYF(0), $2.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
i= new sp_instr_copen(sp->instructions(), lex->spcont, offset);
|
|
|
|
sp->add_instr(i);
|
|
|
|
}
|
2005-12-02 13:07:02 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_proc_stmt_fetch:
|
|
|
|
FETCH_SYM sp_opt_fetch_noise ident INTO
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
uint offset;
|
|
|
|
sp_instr_cfetch *i;
|
|
|
|
|
|
|
|
if (! lex->spcont->find_cursor(&$3, &offset))
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_CURSOR_MISMATCH, MYF(0), $3.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
i= new sp_instr_cfetch(sp->instructions(), lex->spcont, offset);
|
|
|
|
sp->add_instr(i);
|
|
|
|
}
|
|
|
|
sp_fetch_list
|
|
|
|
{ }
|
2005-12-02 13:07:02 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_proc_stmt_close:
|
|
|
|
CLOSE_SYM ident
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
uint offset;
|
|
|
|
sp_instr_cclose *i;
|
|
|
|
|
|
|
|
if (! lex->spcont->find_cursor(&$2, &offset))
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_CURSOR_MISMATCH, MYF(0), $2.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
i= new sp_instr_cclose(sp->instructions(), lex->spcont, offset);
|
|
|
|
sp->add_instr(i);
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_opt_fetch_noise:
|
|
|
|
/* Empty */
|
|
|
|
| NEXT_SYM FROM
|
|
|
|
| FROM
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_fetch_list:
|
|
|
|
ident
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
sp_pcontext *spc= lex->spcont;
|
2006-04-07 16:53:15 +02:00
|
|
|
sp_variable_t *spv;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2006-04-07 16:53:15 +02:00
|
|
|
if (!spc || !(spv = spc->find_variable(&$1)))
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_UNDECLARED_VAR, MYF(0), $1.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* An SP local variable */
|
|
|
|
sp_instr_cfetch *i= (sp_instr_cfetch *)sp->last_instruction();
|
|
|
|
|
|
|
|
i->add_to_varlist(spv);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
sp_fetch_list ',' ident
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
sp_pcontext *spc= lex->spcont;
|
2006-04-07 16:53:15 +02:00
|
|
|
sp_variable_t *spv;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2006-04-07 16:53:15 +02:00
|
|
|
if (!spc || !(spv = spc->find_variable(&$3)))
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_UNDECLARED_VAR, MYF(0), $3.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* An SP local variable */
|
|
|
|
sp_instr_cfetch *i= (sp_instr_cfetch *)sp->last_instruction();
|
|
|
|
|
|
|
|
i->add_to_varlist(spv);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_if:
|
2005-03-04 14:35:28 +01:00
|
|
|
{ Lex->sphead->reset_lex(YYTHD); }
|
|
|
|
expr THEN_SYM
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
sp_pcontext *ctx= lex->spcont;
|
|
|
|
uint ip= sp->instructions();
|
2005-03-04 14:35:28 +01:00
|
|
|
sp_instr_jump_if_not *i = new sp_instr_jump_if_not(ip, ctx,
|
|
|
|
$2, lex);
|
2004-11-12 04:01:46 +01:00
|
|
|
|
|
|
|
sp->push_backpatch(i, ctx->push_label((char *)"", 0));
|
2005-11-04 15:37:39 +01:00
|
|
|
sp->add_cont_backpatch(i);
|
2004-11-12 04:01:46 +01:00
|
|
|
sp->add_instr(i);
|
2005-03-04 14:35:28 +01:00
|
|
|
sp->restore_lex(YYTHD);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
sp_proc_stmts1
|
|
|
|
{
|
|
|
|
sp_head *sp= Lex->sphead;
|
|
|
|
sp_pcontext *ctx= Lex->spcont;
|
|
|
|
uint ip= sp->instructions();
|
|
|
|
sp_instr_jump *i = new sp_instr_jump(ip, ctx);
|
|
|
|
|
|
|
|
sp->add_instr(i);
|
|
|
|
sp->backpatch(ctx->pop_label());
|
|
|
|
sp->push_backpatch(i, ctx->push_label((char *)"", 0));
|
|
|
|
}
|
|
|
|
sp_elseifs
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
|
|
|
|
lex->sphead->backpatch(lex->spcont->pop_label());
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
sp_elseifs:
|
|
|
|
/* Empty */
|
|
|
|
| ELSEIF_SYM sp_if
|
|
|
|
| ELSE sp_proc_stmts1
|
|
|
|
;
|
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
case_stmt_specification:
|
|
|
|
simple_case_stmt
|
|
|
|
| searched_case_stmt
|
|
|
|
;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
simple_case_stmt:
|
|
|
|
CASE_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
case_stmt_action_case(lex);
|
|
|
|
lex->sphead->reset_lex(YYTHD); /* For expr $3 */
|
|
|
|
}
|
|
|
|
expr
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
if (case_stmt_action_expr(lex, $3))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-12-07 15:01:17 +01:00
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
lex->sphead->restore_lex(YYTHD); /* For expr $3 */
|
|
|
|
}
|
|
|
|
simple_when_clause_list
|
|
|
|
else_clause_opt
|
|
|
|
END
|
|
|
|
CASE_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
case_stmt_action_end_case(lex, true);
|
|
|
|
}
|
|
|
|
;
|
2005-12-07 15:01:17 +01:00
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
searched_case_stmt:
|
|
|
|
CASE_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
case_stmt_action_case(lex);
|
|
|
|
}
|
|
|
|
searched_when_clause_list
|
|
|
|
else_clause_opt
|
|
|
|
END
|
|
|
|
CASE_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
case_stmt_action_end_case(lex, false);
|
|
|
|
}
|
|
|
|
;
|
2005-12-07 15:01:17 +01:00
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
simple_when_clause_list:
|
|
|
|
simple_when_clause
|
|
|
|
| simple_when_clause_list simple_when_clause
|
|
|
|
;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
searched_when_clause_list:
|
|
|
|
searched_when_clause
|
|
|
|
| searched_when_clause_list searched_when_clause
|
|
|
|
;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
simple_when_clause:
|
|
|
|
WHEN_SYM
|
|
|
|
{
|
|
|
|
Lex->sphead->reset_lex(YYTHD); /* For expr $3 */
|
|
|
|
}
|
|
|
|
expr
|
|
|
|
{
|
|
|
|
/* Simple case: <caseval> = <whenval> */
|
2004-11-12 04:01:46 +01:00
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
case_stmt_action_when(lex, $3, true);
|
|
|
|
lex->sphead->restore_lex(YYTHD); /* For expr $3 */
|
|
|
|
}
|
|
|
|
THEN_SYM
|
|
|
|
sp_proc_stmts1
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
case_stmt_action_then(lex);
|
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
searched_when_clause:
|
|
|
|
WHEN_SYM
|
|
|
|
{
|
|
|
|
Lex->sphead->reset_lex(YYTHD); /* For expr $3 */
|
|
|
|
}
|
|
|
|
expr
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
case_stmt_action_when(lex, $3, false);
|
|
|
|
lex->sphead->restore_lex(YYTHD); /* For expr $3 */
|
|
|
|
}
|
|
|
|
THEN_SYM
|
|
|
|
sp_proc_stmts1
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
case_stmt_action_then(lex);
|
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
else_clause_opt:
|
|
|
|
/* empty */
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
uint ip= sp->instructions();
|
|
|
|
sp_instr_error *i= new sp_instr_error(ip, lex->spcont,
|
|
|
|
ER_SP_CASE_NOT_FOUND);
|
|
|
|
sp->add_instr(i);
|
|
|
|
}
|
|
|
|
| ELSE sp_proc_stmts1
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_labeled_control:
|
2005-07-06 16:37:57 +02:00
|
|
|
label_ident ':'
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_pcontext *ctx= lex->spcont;
|
|
|
|
sp_label_t *lab= ctx->find_label($1.str);
|
|
|
|
|
|
|
|
if (lab)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_LABEL_REDEFINE, MYF(0), $1.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
lab= lex->spcont->push_label($1.str,
|
|
|
|
lex->sphead->instructions());
|
|
|
|
lab->type= SP_LAB_ITER;
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_unlabeled_control sp_opt_label
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
2002-02-22 12:24:42 +01:00
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
if ($5.str)
|
|
|
|
{
|
|
|
|
sp_label_t *lab= lex->spcont->find_label($5.str);
|
|
|
|
|
|
|
|
if (!lab ||
|
|
|
|
my_strcasecmp(system_charset_info, $5.str, lab->name) != 0)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_LABEL_MISMATCH, MYF(0), $5.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
lex->sphead->backpatch(lex->spcont->pop_label());
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_opt_label:
|
2005-01-16 13:16:23 +01:00
|
|
|
/* Empty */ { $$= null_lex_str; }
|
2005-07-06 16:37:57 +02:00
|
|
|
| label_ident { $$= $1; }
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
sp_unlabeled_control:
|
|
|
|
BEGIN_SYM
|
|
|
|
{ /* QQ This is just a dummy for grouping declarations and statements
|
|
|
|
together. No [[NOT] ATOMIC] yet, and we need to figure out how
|
|
|
|
make it coexist with the existing BEGIN COMMIT/ROLLBACK. */
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_label_t *lab= lex->spcont->last_label();
|
|
|
|
|
|
|
|
lab->type= SP_LAB_BEGIN;
|
Bug#26503 (Illegal SQL exception handler code causes the server to crash)
Before this fix, the parser would accept illegal code in SQL exceptions
handlers, that later causes the runtime to crash when executing the code,
due to memory violations in the exception handler stack.
The root cause of the problem is instructions within an exception handler
that jumps to code located outside of the handler. This is illegal according
to the SQL 2003 standard, since labels located outside the handler are not
supposed to be visible (they are "out of scope"), so any instruction that
jumps to these labels, like ITERATE or LEAVE, should not parse.
The section of the standard that is relevant for this is :
SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003)
section 13.1 <compound statement>,
syntax rule 4
<quote>
The scope of the <beginning label> is CS excluding every <SQL schema
statement> contained in CS and excluding every
<local handler declaration list> contained in CS. <beginning label> shall
not be equivalent to any other <beginning label>s within that scope.
</quote>
With this fix, the C++ class sp_pcontext, which represent the "parsing
context" tree (a.k.a symbol table) of a stored procedure, has been changed
as follows:
- constructors have been cleaned up, so that only building a root node for
the tree is public; building nodes inside a tree is not public.
- a new member, m_label_scope, indicates if a given syntactic context
belongs to a DECLARE HANDLER block,
- label resolution, in the method find_label(), has been changed to
implement the restriction of scope regarding labels used in a compound
statement.
The actions in the parser, when parsing the body of a SQL exception handler,
have been changed as follows:
- the implementation of an exception handler (DECLARE HANDLER) now creates
explicitly a new sp_pcontext, to isolate the code inside the handler from
the containing compound statement context.
- registering exception handlers as a result occurs in the parent context,
see the rule sp_hcond_element
- the code in sp_hcond_list has been cleaned up, to avoid code duplication
In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h
have been removed, since they are unused and broken by design (as seen with
Bug 19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation), representing a stack in a single flag is not possible.
Tests in sp-error have been added to show that illegal constructs are now
rejected.
Tests in sp have been added for code coverage, to show that ITERATE or LEAVE
statements are legal when jumping to a label in scope, inside the body of
an exception handler.
2007-03-14 19:02:32 +01:00
|
|
|
lex->spcont= lex->spcont->push_context(LABEL_DEFAULT_SCOPE);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
sp_decls
|
|
|
|
sp_proc_stmts
|
|
|
|
END
|
2004-08-27 17:48:19 +02:00
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
sp_pcontext *ctx= lex->spcont;
|
|
|
|
|
|
|
|
sp->backpatch(ctx->last_label()); /* We always have a label */
|
|
|
|
if ($3.hndlrs)
|
|
|
|
sp->add_instr(new sp_instr_hpop(sp->instructions(), ctx,
|
|
|
|
$3.hndlrs));
|
|
|
|
if ($3.curs)
|
|
|
|
sp->add_instr(new sp_instr_cpop(sp->instructions(), ctx,
|
|
|
|
$3.curs));
|
|
|
|
lex->spcont= ctx->pop_context();
|
|
|
|
}
|
|
|
|
| LOOP_SYM
|
|
|
|
sp_proc_stmts1 END LOOP_SYM
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
uint ip= lex->sphead->instructions();
|
|
|
|
sp_label_t *lab= lex->spcont->last_label(); /* Jumping back */
|
|
|
|
sp_instr_jump *i = new sp_instr_jump(ip, lex->spcont, lab->ip);
|
|
|
|
|
|
|
|
lex->sphead->add_instr(i);
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2005-03-04 14:35:28 +01:00
|
|
|
| WHILE_SYM
|
|
|
|
{ Lex->sphead->reset_lex(YYTHD); }
|
|
|
|
expr DO_SYM
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
uint ip= sp->instructions();
|
|
|
|
sp_instr_jump_if_not *i = new sp_instr_jump_if_not(ip, lex->spcont,
|
2005-03-04 14:35:28 +01:00
|
|
|
$3, lex);
|
2004-11-12 04:01:46 +01:00
|
|
|
|
|
|
|
/* Jumping forward */
|
|
|
|
sp->push_backpatch(i, lex->spcont->last_label());
|
2005-11-04 15:37:39 +01:00
|
|
|
sp->new_cont_backpatch(i);
|
2004-11-12 04:01:46 +01:00
|
|
|
sp->add_instr(i);
|
2005-03-04 14:35:28 +01:00
|
|
|
sp->restore_lex(YYTHD);
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_proc_stmts1 END WHILE_SYM
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
uint ip= lex->sphead->instructions();
|
|
|
|
sp_label_t *lab= lex->spcont->last_label(); /* Jumping back */
|
|
|
|
sp_instr_jump *i = new sp_instr_jump(ip, lex->spcont, lab->ip);
|
|
|
|
|
|
|
|
lex->sphead->add_instr(i);
|
2005-11-04 15:37:39 +01:00
|
|
|
lex->sphead->do_cont_backpatch();
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2005-03-04 14:35:28 +01:00
|
|
|
| REPEAT_SYM sp_proc_stmts1 UNTIL_SYM
|
|
|
|
{ Lex->sphead->reset_lex(YYTHD); }
|
|
|
|
expr END REPEAT_SYM
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
uint ip= lex->sphead->instructions();
|
|
|
|
sp_label_t *lab= lex->spcont->last_label(); /* Jumping back */
|
|
|
|
sp_instr_jump_if_not *i = new sp_instr_jump_if_not(ip, lex->spcont,
|
2005-03-04 14:35:28 +01:00
|
|
|
$5, lab->ip,
|
|
|
|
lex);
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->sphead->add_instr(i);
|
2005-03-04 14:35:28 +01:00
|
|
|
lex->sphead->restore_lex(YYTHD);
|
2005-11-04 15:37:39 +01:00
|
|
|
/* We can shortcut the cont_backpatch here */
|
|
|
|
i->m_cont_dest= ip+1;
|
2002-10-16 15:55:08 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
trg_action_time:
|
|
|
|
BEFORE_SYM
|
|
|
|
{ Lex->trg_chistics.action_time= TRG_ACTION_BEFORE; }
|
|
|
|
| AFTER_SYM
|
|
|
|
{ Lex->trg_chistics.action_time= TRG_ACTION_AFTER; }
|
|
|
|
;
|
|
|
|
|
|
|
|
trg_event:
|
|
|
|
INSERT
|
|
|
|
{ Lex->trg_chistics.event= TRG_EVENT_INSERT; }
|
|
|
|
| UPDATE_SYM
|
|
|
|
{ Lex->trg_chistics.event= TRG_EVENT_UPDATE; }
|
|
|
|
| DELETE_SYM
|
|
|
|
{ Lex->trg_chistics.event= TRG_EVENT_DELETE; }
|
2002-10-16 15:55:08 +02:00
|
|
|
;
|
2006-01-11 11:35:25 +01:00
|
|
|
/*
|
|
|
|
This part of the parser contains common code for all TABLESPACE
|
|
|
|
commands.
|
|
|
|
CREATE TABLESPACE name ...
|
|
|
|
ALTER TABLESPACE name CHANGE DATAFILE ...
|
|
|
|
ALTER TABLESPACE name ADD DATAFILE ...
|
|
|
|
ALTER TABLESPACE name access_mode
|
2007-02-23 21:48:15 +01:00
|
|
|
CREATE LOGFILE GROUP_SYM name ...
|
|
|
|
ALTER LOGFILE GROUP_SYM name ADD UNDOFILE ..
|
|
|
|
ALTER LOGFILE GROUP_SYM name ADD REDOFILE ..
|
2006-01-11 11:35:25 +01:00
|
|
|
DROP TABLESPACE name
|
2007-02-23 21:48:15 +01:00
|
|
|
DROP LOGFILE GROUP_SYM name
|
2006-01-11 11:35:25 +01:00
|
|
|
*/
|
|
|
|
change_tablespace_access:
|
|
|
|
tablespace_name
|
|
|
|
ts_access_mode
|
|
|
|
;
|
|
|
|
|
|
|
|
change_tablespace_info:
|
|
|
|
tablespace_name
|
|
|
|
CHANGE ts_datafile
|
|
|
|
change_ts_option_list
|
|
|
|
;
|
|
|
|
|
|
|
|
tablespace_info:
|
|
|
|
tablespace_name
|
|
|
|
ADD ts_datafile
|
|
|
|
opt_logfile_group_name
|
|
|
|
tablespace_option_list
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_logfile_group_name:
|
|
|
|
/* empty */ {}
|
2007-02-23 21:48:15 +01:00
|
|
|
| USE_SYM LOGFILE_SYM GROUP_SYM ident
|
2006-01-11 11:35:25 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->logfile_group_name= $4.str;
|
|
|
|
};
|
|
|
|
|
|
|
|
alter_tablespace_info:
|
|
|
|
tablespace_name
|
|
|
|
ADD ts_datafile
|
|
|
|
alter_tablespace_option_list
|
|
|
|
{
|
|
|
|
Lex->alter_tablespace_info->ts_alter_tablespace_type= ALTER_TABLESPACE_ADD_FILE;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
tablespace_name
|
|
|
|
DROP ts_datafile
|
|
|
|
alter_tablespace_option_list
|
|
|
|
{
|
|
|
|
Lex->alter_tablespace_info->ts_alter_tablespace_type= ALTER_TABLESPACE_DROP_FILE;
|
|
|
|
};
|
|
|
|
|
|
|
|
logfile_group_info:
|
|
|
|
logfile_group_name
|
|
|
|
add_log_file
|
|
|
|
logfile_group_option_list
|
|
|
|
;
|
|
|
|
|
|
|
|
alter_logfile_group_info:
|
|
|
|
logfile_group_name
|
|
|
|
add_log_file
|
|
|
|
alter_logfile_group_option_list
|
|
|
|
;
|
|
|
|
|
|
|
|
add_log_file:
|
|
|
|
ADD lg_undofile
|
|
|
|
| ADD lg_redofile
|
|
|
|
;
|
|
|
|
|
|
|
|
change_ts_option_list:
|
|
|
|
/* empty */ {}
|
|
|
|
change_ts_options
|
|
|
|
;
|
|
|
|
|
|
|
|
change_ts_options:
|
|
|
|
change_ts_option
|
|
|
|
| change_ts_options change_ts_option
|
|
|
|
| change_ts_options ',' change_ts_option
|
|
|
|
;
|
|
|
|
|
|
|
|
change_ts_option:
|
|
|
|
opt_ts_initial_size
|
|
|
|
| opt_ts_autoextend_size
|
|
|
|
| opt_ts_max_size
|
|
|
|
;
|
|
|
|
|
|
|
|
tablespace_option_list:
|
|
|
|
/* empty */ {}
|
|
|
|
tablespace_options
|
|
|
|
;
|
|
|
|
|
|
|
|
tablespace_options:
|
|
|
|
tablespace_option
|
|
|
|
| tablespace_options tablespace_option
|
|
|
|
| tablespace_options ',' tablespace_option
|
|
|
|
;
|
|
|
|
|
|
|
|
tablespace_option:
|
|
|
|
opt_ts_initial_size
|
|
|
|
| opt_ts_autoextend_size
|
|
|
|
| opt_ts_max_size
|
|
|
|
| opt_ts_extent_size
|
|
|
|
| opt_ts_nodegroup
|
|
|
|
| opt_ts_engine
|
|
|
|
| ts_wait
|
|
|
|
| opt_ts_comment
|
|
|
|
;
|
|
|
|
|
|
|
|
alter_tablespace_option_list:
|
|
|
|
/* empty */ {}
|
|
|
|
alter_tablespace_options
|
|
|
|
;
|
|
|
|
|
|
|
|
alter_tablespace_options:
|
|
|
|
alter_tablespace_option
|
|
|
|
| alter_tablespace_options alter_tablespace_option
|
|
|
|
| alter_tablespace_options ',' alter_tablespace_option
|
|
|
|
;
|
|
|
|
|
|
|
|
alter_tablespace_option:
|
|
|
|
opt_ts_initial_size
|
|
|
|
| opt_ts_autoextend_size
|
|
|
|
| opt_ts_max_size
|
|
|
|
| opt_ts_engine
|
|
|
|
| ts_wait
|
|
|
|
;
|
|
|
|
|
|
|
|
logfile_group_option_list:
|
|
|
|
/* empty */ {}
|
|
|
|
logfile_group_options
|
|
|
|
;
|
|
|
|
|
|
|
|
logfile_group_options:
|
|
|
|
logfile_group_option
|
|
|
|
| logfile_group_options logfile_group_option
|
|
|
|
| logfile_group_options ',' logfile_group_option
|
|
|
|
;
|
|
|
|
|
|
|
|
logfile_group_option:
|
|
|
|
opt_ts_initial_size
|
|
|
|
| opt_ts_undo_buffer_size
|
|
|
|
| opt_ts_redo_buffer_size
|
|
|
|
| opt_ts_nodegroup
|
|
|
|
| opt_ts_engine
|
|
|
|
| ts_wait
|
|
|
|
| opt_ts_comment
|
|
|
|
;
|
|
|
|
|
|
|
|
alter_logfile_group_option_list:
|
|
|
|
/* empty */ {}
|
|
|
|
alter_logfile_group_options
|
|
|
|
;
|
|
|
|
|
|
|
|
alter_logfile_group_options:
|
|
|
|
alter_logfile_group_option
|
|
|
|
| alter_logfile_group_options alter_logfile_group_option
|
|
|
|
| alter_logfile_group_options ',' alter_logfile_group_option
|
|
|
|
;
|
|
|
|
|
|
|
|
alter_logfile_group_option:
|
|
|
|
opt_ts_initial_size
|
|
|
|
| opt_ts_engine
|
|
|
|
| ts_wait
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
ts_datafile:
|
|
|
|
DATAFILE_SYM TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->data_file_name= $2.str;
|
|
|
|
};
|
|
|
|
|
|
|
|
lg_undofile:
|
|
|
|
UNDOFILE_SYM TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->undo_file_name= $2.str;
|
|
|
|
};
|
|
|
|
|
|
|
|
lg_redofile:
|
|
|
|
REDOFILE_SYM TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->redo_file_name= $2.str;
|
|
|
|
};
|
|
|
|
|
|
|
|
tablespace_name:
|
|
|
|
ident
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info= new st_alter_tablespace();
|
|
|
|
lex->alter_tablespace_info->tablespace_name= $1.str;
|
|
|
|
lex->sql_command= SQLCOM_ALTER_TABLESPACE;
|
|
|
|
};
|
|
|
|
|
|
|
|
logfile_group_name:
|
|
|
|
ident
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info= new st_alter_tablespace();
|
|
|
|
lex->alter_tablespace_info->logfile_group_name= $1.str;
|
|
|
|
lex->sql_command= SQLCOM_ALTER_TABLESPACE;
|
|
|
|
};
|
|
|
|
|
|
|
|
ts_access_mode:
|
|
|
|
READ_ONLY_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->ts_access_mode= TS_READ_ONLY;
|
|
|
|
}
|
|
|
|
| READ_WRITE_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->ts_access_mode= TS_READ_WRITE;
|
|
|
|
}
|
|
|
|
| NOT_SYM ACCESSIBLE_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->ts_access_mode= TS_NOT_ACCESSIBLE;
|
|
|
|
};
|
|
|
|
|
|
|
|
opt_ts_initial_size:
|
|
|
|
INITIAL_SIZE_SYM opt_equal size_number
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->initial_size= $3;
|
|
|
|
};
|
|
|
|
|
|
|
|
opt_ts_autoextend_size:
|
|
|
|
AUTOEXTEND_SIZE_SYM opt_equal size_number
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->autoextend_size= $3;
|
|
|
|
};
|
|
|
|
|
|
|
|
opt_ts_max_size:
|
|
|
|
MAX_SIZE_SYM opt_equal size_number
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->max_size= $3;
|
|
|
|
};
|
|
|
|
|
|
|
|
opt_ts_extent_size:
|
|
|
|
EXTENT_SIZE_SYM opt_equal size_number
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->extent_size= $3;
|
|
|
|
};
|
|
|
|
|
|
|
|
opt_ts_undo_buffer_size:
|
|
|
|
UNDO_BUFFER_SIZE_SYM opt_equal size_number
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->undo_buffer_size= $3;
|
|
|
|
};
|
|
|
|
|
|
|
|
opt_ts_redo_buffer_size:
|
|
|
|
REDO_BUFFER_SIZE_SYM opt_equal size_number
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->redo_buffer_size= $3;
|
|
|
|
};
|
|
|
|
|
|
|
|
opt_ts_nodegroup:
|
2006-08-07 18:02:28 +02:00
|
|
|
NODEGROUP_SYM opt_equal real_ulong_num
|
2006-01-11 11:35:25 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
if (lex->alter_tablespace_info->nodegroup_id != UNDEF_NODEGROUP)
|
|
|
|
{
|
2006-02-06 21:52:27 +01:00
|
|
|
my_error(ER_FILEGROUP_OPTION_ONLY_ONCE,MYF(0),"NODEGROUP");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-11 11:35:25 +01:00
|
|
|
}
|
|
|
|
lex->alter_tablespace_info->nodegroup_id= $3;
|
|
|
|
};
|
|
|
|
|
|
|
|
opt_ts_comment:
|
|
|
|
COMMENT_SYM opt_equal TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
if (lex->alter_tablespace_info->ts_comment != NULL)
|
|
|
|
{
|
2006-02-06 21:52:27 +01:00
|
|
|
my_error(ER_FILEGROUP_OPTION_ONLY_ONCE,MYF(0),"COMMENT");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-11 11:35:25 +01:00
|
|
|
}
|
|
|
|
lex->alter_tablespace_info->ts_comment= $3.str;
|
|
|
|
};
|
|
|
|
|
|
|
|
opt_ts_engine:
|
|
|
|
opt_storage ENGINE_SYM opt_equal storage_engines
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-04-24 18:26:30 +02:00
|
|
|
if (lex->alter_tablespace_info->storage_engine != NULL)
|
2006-01-11 11:35:25 +01:00
|
|
|
{
|
2006-02-06 21:52:27 +01:00
|
|
|
my_error(ER_FILEGROUP_OPTION_ONLY_ONCE,MYF(0),
|
2006-01-11 11:35:25 +01:00
|
|
|
"STORAGE ENGINE");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-11 11:35:25 +01:00
|
|
|
}
|
2006-05-28 14:51:01 +02:00
|
|
|
lex->alter_tablespace_info->storage_engine= $4;
|
2006-01-11 11:35:25 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
opt_ts_wait:
|
2006-05-28 14:51:01 +02:00
|
|
|
/* empty */
|
2006-01-11 11:35:25 +01:00
|
|
|
| ts_wait
|
|
|
|
;
|
|
|
|
|
|
|
|
ts_wait:
|
|
|
|
WAIT_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->wait_until_completed= TRUE;
|
|
|
|
}
|
|
|
|
| NO_WAIT_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
if (!(lex->alter_tablespace_info->wait_until_completed))
|
|
|
|
{
|
2006-02-06 21:52:27 +01:00
|
|
|
my_error(ER_FILEGROUP_OPTION_ONLY_ONCE,MYF(0),"NO_WAIT");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-11 11:35:25 +01:00
|
|
|
}
|
|
|
|
lex->alter_tablespace_info->wait_until_completed= FALSE;
|
|
|
|
};
|
|
|
|
|
|
|
|
size_number:
|
2006-08-07 18:02:28 +02:00
|
|
|
real_ulong_num { $$= $1;}
|
2006-01-11 11:35:25 +01:00
|
|
|
| IDENT
|
|
|
|
{
|
2006-11-30 02:40:42 +01:00
|
|
|
ulonglong number;
|
2006-01-11 11:35:25 +01:00
|
|
|
uint text_shift_number= 0;
|
|
|
|
longlong prefix_number;
|
|
|
|
char *start_ptr= $1.str;
|
2006-10-16 18:57:33 +02:00
|
|
|
uint str_len= $1.length;
|
2006-01-23 09:31:03 +01:00
|
|
|
char *end_ptr= start_ptr + str_len;
|
2006-01-11 11:35:25 +01:00
|
|
|
int error;
|
|
|
|
prefix_number= my_strtoll10(start_ptr, &end_ptr, &error);
|
|
|
|
if ((start_ptr + str_len - 1) == end_ptr)
|
|
|
|
{
|
|
|
|
switch (end_ptr[0])
|
|
|
|
{
|
|
|
|
case 'g':
|
|
|
|
case 'G':
|
|
|
|
text_shift_number+=10;
|
|
|
|
case 'm':
|
|
|
|
case 'M':
|
|
|
|
text_shift_number+=10;
|
|
|
|
case 'k':
|
|
|
|
case 'K':
|
|
|
|
text_shift_number+=10;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
{
|
|
|
|
my_error(ER_WRONG_SIZE_NUMBER, MYF(0));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-11 11:35:25 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (prefix_number >> 31)
|
|
|
|
{
|
|
|
|
my_error(ER_SIZE_OVERFLOW_ERROR, MYF(0));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-11 11:35:25 +01:00
|
|
|
}
|
|
|
|
number= prefix_number << text_shift_number;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
my_error(ER_WRONG_SIZE_NUMBER, MYF(0));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-11 11:35:25 +01:00
|
|
|
}
|
|
|
|
$$= number;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
/*
|
|
|
|
End tablespace part
|
|
|
|
*/
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
create2:
|
2004-09-13 11:19:38 +02:00
|
|
|
'(' create2a {}
|
2005-07-18 13:31:02 +02:00
|
|
|
| opt_create_table_options
|
|
|
|
opt_partitioning {}
|
|
|
|
create3 {}
|
2004-09-13 11:19:38 +02:00
|
|
|
| LIKE table_ident
|
|
|
|
{
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
|
|
|
|
lex->create_info.options|= HA_LEX_CREATE_TABLE_LIKE;
|
|
|
|
if (!lex->select_lex.add_table_to_list(thd, $2, NULL, 0, TL_READ))
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-09-13 11:19:38 +02:00
|
|
|
}
|
|
|
|
| '(' LIKE table_ident ')'
|
|
|
|
{
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
|
|
|
|
lex->create_info.options|= HA_LEX_CREATE_TABLE_LIKE;
|
|
|
|
if (!lex->select_lex.add_table_to_list(thd, $3, NULL, 0, TL_READ))
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-09-13 11:19:38 +02:00
|
|
|
}
|
2003-08-11 21:44:43 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-06-30 22:24:03 +02:00
|
|
|
create2a:
|
2005-07-18 13:31:02 +02:00
|
|
|
field_list ')' opt_create_table_options
|
|
|
|
opt_partitioning {}
|
|
|
|
create3 {}
|
|
|
|
| opt_partitioning {}
|
|
|
|
create_select ')'
|
|
|
|
{ Select->set_braces(1);} union_opt {}
|
2003-06-17 15:20:07 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
create3:
|
2000-10-14 02:16:35 +02:00
|
|
|
/* empty */ {}
|
2003-06-30 22:24:03 +02:00
|
|
|
| opt_duplicate opt_as create_select
|
2003-08-18 23:08:08 +02:00
|
|
|
{ Select->set_braces(0);} union_clause {}
|
2003-06-30 22:24:03 +02:00
|
|
|
| opt_duplicate opt_as '(' create_select ')'
|
2003-08-18 23:08:08 +02:00
|
|
|
{ Select->set_braces(1);} union_opt {}
|
2003-06-17 15:20:07 +02:00
|
|
|
;
|
|
|
|
|
2005-07-18 13:31:02 +02:00
|
|
|
/*
|
|
|
|
This part of the parser is about handling of the partition information.
|
|
|
|
|
2005-11-18 16:38:01 +01:00
|
|
|
It's first version was written by Mikael Ronström with lots of answers to
|
2005-07-18 13:31:02 +02:00
|
|
|
questions provided by Antony Curtis.
|
|
|
|
|
|
|
|
The partition grammar can be called from three places.
|
|
|
|
1) CREATE TABLE ... PARTITION ..
|
|
|
|
2) ALTER TABLE table_name PARTITION ...
|
|
|
|
3) PARTITION ...
|
|
|
|
|
|
|
|
The first place is called when a new table is created from a MySQL client.
|
|
|
|
The second place is called when a table is altered with the ALTER TABLE
|
|
|
|
command from a MySQL client.
|
|
|
|
The third place is called when opening an frm file and finding partition
|
|
|
|
info in the .frm file. It is necessary to avoid allowing PARTITION to be
|
|
|
|
an allowed entry point for SQL client queries. This is arranged by setting
|
|
|
|
some state variables before arriving here.
|
|
|
|
|
|
|
|
To be able to handle errors we will only set error code in this code
|
|
|
|
and handle the error condition in the function calling the parser. This
|
|
|
|
is necessary to ensure we can also handle errors when calling the parser
|
|
|
|
from the openfrm function.
|
|
|
|
*/
|
|
|
|
opt_partitioning:
|
|
|
|
/* empty */ {}
|
|
|
|
| partitioning
|
|
|
|
;
|
|
|
|
|
|
|
|
partitioning:
|
|
|
|
PARTITION_SYM
|
2005-08-19 16:26:05 +02:00
|
|
|
{
|
2006-10-26 19:11:09 +02:00
|
|
|
#ifdef WITH_PARTITION_STORAGE_ENGINE
|
2005-08-19 16:26:05 +02:00
|
|
|
LEX *lex= Lex;
|
2007-03-02 17:43:45 +01:00
|
|
|
LEX_STRING partition_name={C_STRING_WITH_LEN("partition")};
|
|
|
|
if (!plugin_is_ready(&partition_name, MYSQL_STORAGE_ENGINE_PLUGIN))
|
|
|
|
{
|
|
|
|
my_error(ER_FEATURE_DISABLED, MYF(0),
|
|
|
|
"partitioning", "--with-partition");
|
2007-04-16 10:37:50 +02:00
|
|
|
MYSQL_YYABORT;
|
2007-03-02 17:43:45 +01:00
|
|
|
}
|
2005-08-19 16:26:05 +02:00
|
|
|
lex->part_info= new partition_info();
|
|
|
|
if (!lex->part_info)
|
|
|
|
{
|
2006-01-17 08:40:00 +01:00
|
|
|
mem_alloc_error(sizeof(partition_info));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
2006-01-17 08:40:00 +01:00
|
|
|
if (lex->sql_command == SQLCOM_ALTER_TABLE)
|
|
|
|
{
|
|
|
|
lex->alter_info.flags|= ALTER_PARTITION;
|
|
|
|
}
|
2006-10-26 19:11:09 +02:00
|
|
|
#else
|
|
|
|
my_error(ER_FEATURE_DISABLED, MYF(0),
|
|
|
|
"partitioning", "--with-partition");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-10-26 19:11:09 +02:00
|
|
|
#endif
|
|
|
|
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
2005-07-18 13:31:02 +02:00
|
|
|
partition
|
|
|
|
;
|
|
|
|
|
|
|
|
partition_entry:
|
|
|
|
PARTITION_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-01-17 08:40:00 +01:00
|
|
|
if (!lex->part_info)
|
2005-07-18 13:31:02 +02:00
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_PARTITION_ENTRY_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
2006-01-17 08:40:00 +01:00
|
|
|
/*
|
|
|
|
We enter here when opening the frm file to translate
|
|
|
|
partition info string into part_info data structure.
|
|
|
|
*/
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
2005-08-19 16:26:05 +02:00
|
|
|
partition {}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
partition:
|
2005-08-19 16:26:05 +02:00
|
|
|
BY part_type_def opt_no_parts {} opt_sub_part {} part_defs
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_type_def:
|
|
|
|
opt_linear KEY_SYM '(' part_field_list ')'
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->part_info->list_of_part_fields= TRUE;
|
|
|
|
lex->part_info->part_type= HASH_PARTITION;
|
|
|
|
}
|
|
|
|
| opt_linear HASH_SYM
|
|
|
|
{ Lex->part_info->part_type= HASH_PARTITION; }
|
|
|
|
part_func {}
|
|
|
|
| RANGE_SYM
|
|
|
|
{ Lex->part_info->part_type= RANGE_PARTITION; }
|
|
|
|
part_func {}
|
|
|
|
| LIST_SYM
|
|
|
|
{ Lex->part_info->part_type= LIST_PARTITION; }
|
2005-08-19 16:26:05 +02:00
|
|
|
part_func {}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
opt_linear:
|
|
|
|
/* empty */ {}
|
|
|
|
| LINEAR_SYM
|
2005-08-19 16:26:05 +02:00
|
|
|
{ Lex->part_info->linear_hash_ind= TRUE;}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_field_list:
|
2006-01-17 08:40:00 +01:00
|
|
|
/* empty */ {}
|
|
|
|
| part_field_item_list {}
|
|
|
|
;
|
|
|
|
|
|
|
|
part_field_item_list:
|
2005-07-18 13:31:02 +02:00
|
|
|
part_field_item {}
|
2006-01-17 08:40:00 +01:00
|
|
|
| part_field_item_list ',' part_field_item {}
|
2005-08-19 16:26:05 +02:00
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_field_item:
|
|
|
|
ident
|
|
|
|
{
|
2006-01-17 08:40:00 +01:00
|
|
|
if (Lex->part_info->part_field_list.push_back($1.str))
|
|
|
|
{
|
|
|
|
mem_alloc_error(1);
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-17 08:40:00 +01:00
|
|
|
}
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_func:
|
|
|
|
'(' remember_name part_func_expr remember_end ')'
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
uint expr_len= (uint)($4 - $2) - 1;
|
|
|
|
lex->part_info->list_of_part_fields= FALSE;
|
|
|
|
lex->part_info->part_expr= $3;
|
2006-03-01 09:42:33 +01:00
|
|
|
lex->part_info->part_func_string= (char* ) sql_memdup($2+1, expr_len);
|
2005-07-18 13:31:02 +02:00
|
|
|
lex->part_info->part_func_len= expr_len;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
sub_part_func:
|
|
|
|
'(' remember_name part_func_expr remember_end ')'
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
uint expr_len= (uint)($4 - $2) - 1;
|
|
|
|
lex->part_info->list_of_subpart_fields= FALSE;
|
|
|
|
lex->part_info->subpart_expr= $3;
|
2006-03-01 09:42:33 +01:00
|
|
|
lex->part_info->subpart_func_string= (char* ) sql_memdup($2+1, expr_len);
|
2005-07-18 13:31:02 +02:00
|
|
|
lex->part_info->subpart_func_len= expr_len;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
opt_no_parts:
|
|
|
|
/* empty */ {}
|
2006-08-07 18:02:28 +02:00
|
|
|
| PARTITIONS_SYM real_ulong_num
|
2005-07-18 13:31:02 +02:00
|
|
|
{
|
|
|
|
uint no_parts= $2;
|
2006-01-17 08:40:00 +01:00
|
|
|
LEX *lex= Lex;
|
2005-07-18 13:31:02 +02:00
|
|
|
if (no_parts == 0)
|
|
|
|
{
|
|
|
|
my_error(ER_NO_PARTS_ERROR, MYF(0), "partitions");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
2006-01-17 08:40:00 +01:00
|
|
|
|
|
|
|
lex->part_info->no_parts= no_parts;
|
|
|
|
lex->part_info->use_default_no_partitions= FALSE;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
opt_sub_part:
|
|
|
|
/* empty */ {}
|
|
|
|
| SUBPARTITION_SYM BY opt_linear HASH_SYM sub_part_func
|
|
|
|
{ Lex->part_info->subpart_type= HASH_PARTITION; }
|
|
|
|
opt_no_subparts {}
|
|
|
|
| SUBPARTITION_SYM BY opt_linear KEY_SYM
|
|
|
|
'(' sub_part_field_list ')'
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->part_info->subpart_type= HASH_PARTITION;
|
|
|
|
lex->part_info->list_of_subpart_fields= TRUE;
|
|
|
|
}
|
2005-08-19 16:26:05 +02:00
|
|
|
opt_no_subparts {}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
sub_part_field_list:
|
|
|
|
sub_part_field_item {}
|
2005-08-19 16:26:05 +02:00
|
|
|
| sub_part_field_list ',' sub_part_field_item {}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
sub_part_field_item:
|
|
|
|
ident
|
2006-01-17 08:40:00 +01:00
|
|
|
{
|
|
|
|
if (Lex->part_info->subpart_field_list.push_back($1.str))
|
|
|
|
{
|
|
|
|
mem_alloc_error(1);
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-17 08:40:00 +01:00
|
|
|
}
|
|
|
|
}
|
2005-08-19 16:26:05 +02:00
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_func_expr:
|
|
|
|
bit_expr
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
bool not_corr_func;
|
|
|
|
not_corr_func= !lex->safe_to_cache_query;
|
|
|
|
lex->safe_to_cache_query= 1;
|
|
|
|
if (not_corr_func)
|
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_CONST_EXPR_IN_PARTITION_FUNC_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
|
|
|
$$=$1;
|
|
|
|
}
|
2005-08-19 16:26:05 +02:00
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
opt_no_subparts:
|
|
|
|
/* empty */ {}
|
2006-08-07 18:02:28 +02:00
|
|
|
| SUBPARTITIONS_SYM real_ulong_num
|
2005-07-18 13:31:02 +02:00
|
|
|
{
|
|
|
|
uint no_parts= $2;
|
2006-01-17 08:40:00 +01:00
|
|
|
LEX *lex= Lex;
|
2005-07-18 13:31:02 +02:00
|
|
|
if (no_parts == 0)
|
|
|
|
{
|
|
|
|
my_error(ER_NO_PARTS_ERROR, MYF(0), "subpartitions");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
2006-01-17 08:40:00 +01:00
|
|
|
lex->part_info->no_subparts= no_parts;
|
|
|
|
lex->part_info->use_default_no_subpartitions= FALSE;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_defs:
|
|
|
|
/* empty */
|
|
|
|
{}
|
|
|
|
| '(' part_def_list ')'
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
partition_info *part_info= lex->part_info;
|
2006-01-17 08:40:00 +01:00
|
|
|
uint count_curr_parts= part_info->partitions.elements;
|
2005-07-18 13:31:02 +02:00
|
|
|
if (part_info->no_parts != 0)
|
|
|
|
{
|
|
|
|
if (part_info->no_parts !=
|
2006-01-17 08:40:00 +01:00
|
|
|
count_curr_parts)
|
2005-07-18 13:31:02 +02:00
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_PARTITION_WRONG_NO_PART_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
|
|
|
}
|
2006-01-17 08:40:00 +01:00
|
|
|
else if (count_curr_parts > 0)
|
2005-07-18 13:31:02 +02:00
|
|
|
{
|
2006-01-17 08:40:00 +01:00
|
|
|
part_info->no_parts= count_curr_parts;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
|
|
|
part_info->count_curr_subparts= 0;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_def_list:
|
|
|
|
part_definition {}
|
2005-08-19 16:26:05 +02:00
|
|
|
| part_def_list ',' part_definition {}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_definition:
|
|
|
|
PARTITION_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
partition_info *part_info= lex->part_info;
|
|
|
|
partition_element *p_elem= new partition_element();
|
2006-02-01 21:38:35 +01:00
|
|
|
|
|
|
|
if (!p_elem || part_info->partitions.push_back(p_elem))
|
2005-07-18 13:31:02 +02:00
|
|
|
{
|
2006-02-01 21:38:35 +01:00
|
|
|
mem_alloc_error(sizeof(partition_element));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
2006-02-01 21:38:35 +01:00
|
|
|
p_elem->part_state= PART_NORMAL;
|
2005-07-18 13:31:02 +02:00
|
|
|
part_info->curr_part_elem= p_elem;
|
|
|
|
part_info->current_partition= p_elem;
|
|
|
|
part_info->use_default_partitions= FALSE;
|
2006-01-17 08:40:00 +01:00
|
|
|
part_info->use_default_no_partitions= FALSE;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
|
|
|
part_name {}
|
|
|
|
opt_part_values {}
|
|
|
|
opt_part_options {}
|
2005-08-19 16:26:05 +02:00
|
|
|
opt_sub_partition {}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_name:
|
2006-04-10 19:48:58 +02:00
|
|
|
ident
|
2006-01-17 08:40:00 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
partition_info *part_info= lex->part_info;
|
|
|
|
partition_element *p_elem= part_info->curr_part_elem;
|
|
|
|
p_elem->partition_name= $1.str;
|
|
|
|
}
|
2005-08-19 16:26:05 +02:00
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
opt_part_values:
|
|
|
|
/* empty */
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
if (! lex->is_partition_management())
|
2005-07-18 13:31:02 +02:00
|
|
|
{
|
2005-08-19 16:26:05 +02:00
|
|
|
if (lex->part_info->part_type == RANGE_PARTITION)
|
|
|
|
{
|
|
|
|
my_error(ER_PARTITION_REQUIRES_VALUES_ERROR, MYF(0),
|
|
|
|
"RANGE", "LESS THAN");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
if (lex->part_info->part_type == LIST_PARTITION)
|
|
|
|
{
|
|
|
|
my_error(ER_PARTITION_REQUIRES_VALUES_ERROR, MYF(0),
|
|
|
|
"LIST", "IN");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
2006-03-09 18:19:34 +01:00
|
|
|
else
|
|
|
|
lex->part_info->part_type= HASH_PARTITION;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
|
|
|
| VALUES LESS_SYM THAN_SYM part_func_max
|
|
|
|
{
|
2005-08-19 16:26:05 +02:00
|
|
|
LEX *lex= Lex;
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
if (! lex->is_partition_management())
|
2005-07-18 13:31:02 +02:00
|
|
|
{
|
2005-08-19 16:26:05 +02:00
|
|
|
if (Lex->part_info->part_type != RANGE_PARTITION)
|
|
|
|
{
|
|
|
|
my_error(ER_PARTITION_WRONG_VALUES_ERROR, MYF(0),
|
|
|
|
"RANGE", "LESS THAN");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
2006-03-09 18:19:34 +01:00
|
|
|
else
|
|
|
|
lex->part_info->part_type= RANGE_PARTITION;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
|
|
|
| VALUES IN_SYM '(' part_list_func ')'
|
|
|
|
{
|
2005-08-19 16:26:05 +02:00
|
|
|
LEX *lex= Lex;
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
if (! lex->is_partition_management())
|
2005-07-18 13:31:02 +02:00
|
|
|
{
|
2005-08-19 16:26:05 +02:00
|
|
|
if (Lex->part_info->part_type != LIST_PARTITION)
|
|
|
|
{
|
|
|
|
my_error(ER_PARTITION_WRONG_VALUES_ERROR, MYF(0),
|
|
|
|
"LIST", "IN");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
2006-03-09 18:19:34 +01:00
|
|
|
else
|
|
|
|
lex->part_info->part_type= LIST_PARTITION;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_func_max:
|
2006-06-05 20:55:22 +02:00
|
|
|
max_value_sym
|
2005-07-18 13:31:02 +02:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
if (lex->part_info->defined_max_value)
|
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_PARTITION_MAXVALUE_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
|
|
|
lex->part_info->defined_max_value= TRUE;
|
2006-04-18 04:51:34 +02:00
|
|
|
lex->part_info->curr_part_elem->max_value= TRUE;
|
2005-07-22 21:17:05 +02:00
|
|
|
lex->part_info->curr_part_elem->range_value= LONGLONG_MAX;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
|
|
|
| part_range_func
|
|
|
|
{
|
|
|
|
if (Lex->part_info->defined_max_value)
|
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_PARTITION_MAXVALUE_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
2006-04-11 04:29:11 +02:00
|
|
|
if (Lex->part_info->curr_part_elem->has_null_value)
|
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_NULL_IN_VALUES_LESS_THAN));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-04-11 04:29:11 +02:00
|
|
|
}
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
2006-06-05 20:55:22 +02:00
|
|
|
max_value_sym:
|
|
|
|
MAX_VALUE_SYM
|
|
|
|
| '(' MAX_VALUE_SYM ')'
|
|
|
|
;
|
|
|
|
|
2005-07-18 13:31:02 +02:00
|
|
|
part_range_func:
|
|
|
|
'(' part_bit_expr ')'
|
|
|
|
{
|
2006-04-18 04:51:34 +02:00
|
|
|
partition_info *part_info= Lex->part_info;
|
|
|
|
if (!($2->unsigned_flag))
|
|
|
|
part_info->curr_part_elem->signed_flag= TRUE;
|
|
|
|
part_info->curr_part_elem->range_value= $2->value;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_list_func:
|
|
|
|
part_list_item {}
|
2005-08-19 16:26:05 +02:00
|
|
|
| part_list_func ',' part_list_item {}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_list_item:
|
|
|
|
part_bit_expr
|
|
|
|
{
|
2006-03-07 12:25:08 +01:00
|
|
|
part_elem_value *value_ptr= $1;
|
2006-04-18 04:51:34 +02:00
|
|
|
partition_info *part_info= Lex->part_info;
|
|
|
|
if (!value_ptr->unsigned_flag)
|
|
|
|
part_info->curr_part_elem->signed_flag= TRUE;
|
2006-03-07 12:25:08 +01:00
|
|
|
if (!value_ptr->null_value &&
|
2006-04-18 04:51:34 +02:00
|
|
|
part_info->curr_part_elem->
|
|
|
|
list_val_list.push_back(value_ptr))
|
2005-07-22 20:47:05 +02:00
|
|
|
{
|
2006-03-07 12:25:08 +01:00
|
|
|
mem_alloc_error(sizeof(part_elem_value));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-22 20:47:05 +02:00
|
|
|
}
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
part_bit_expr:
|
|
|
|
bit_expr
|
|
|
|
{
|
|
|
|
Item *part_expr= $1;
|
2006-01-17 08:40:00 +01:00
|
|
|
THD *thd= YYTHD;
|
2007-01-27 02:46:45 +01:00
|
|
|
LEX *lex= thd->lex;
|
2005-07-18 13:31:02 +02:00
|
|
|
Name_resolution_context *context= &lex->current_select->context;
|
|
|
|
TABLE_LIST *save_list= context->table_list;
|
2006-01-17 08:40:00 +01:00
|
|
|
const char *save_where= thd->where;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
context->table_list= 0;
|
2006-01-17 08:40:00 +01:00
|
|
|
thd->where= "partition function";
|
2006-03-07 12:25:08 +01:00
|
|
|
|
|
|
|
part_elem_value *value_ptr=
|
|
|
|
(part_elem_value*)sql_alloc(sizeof(part_elem_value));
|
|
|
|
if (!value_ptr)
|
|
|
|
{
|
|
|
|
mem_alloc_error(sizeof(part_elem_value));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-03-07 12:25:08 +01:00
|
|
|
}
|
2006-09-26 22:30:39 +02:00
|
|
|
if (part_expr->walk(&Item::check_partition_func_processor, 0,
|
|
|
|
NULL))
|
2006-06-20 16:57:02 +02:00
|
|
|
{
|
|
|
|
my_error(ER_PARTITION_FUNCTION_IS_NOT_ALLOWED, MYF(0));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-06-20 16:57:02 +02:00
|
|
|
}
|
2006-01-17 08:40:00 +01:00
|
|
|
if (part_expr->fix_fields(YYTHD, (Item**)0) ||
|
|
|
|
((context->table_list= save_list), FALSE) ||
|
|
|
|
(!part_expr->const_item()) ||
|
|
|
|
(!lex->safe_to_cache_query))
|
2005-07-18 13:31:02 +02:00
|
|
|
{
|
2006-06-20 16:57:02 +02:00
|
|
|
my_error(ER_NO_CONST_EXPR_IN_RANGE_OR_LIST_ERROR, MYF(0));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
2006-01-17 08:40:00 +01:00
|
|
|
thd->where= save_where;
|
2006-03-07 12:25:08 +01:00
|
|
|
value_ptr->value= part_expr->val_int();
|
2006-04-18 04:51:34 +02:00
|
|
|
value_ptr->unsigned_flag= TRUE;
|
|
|
|
if (!part_expr->unsigned_flag &&
|
|
|
|
value_ptr->value < 0)
|
|
|
|
value_ptr->unsigned_flag= FALSE;
|
2006-03-07 12:25:08 +01:00
|
|
|
if ((value_ptr->null_value= part_expr->null_value))
|
|
|
|
{
|
|
|
|
if (Lex->part_info->curr_part_elem->has_null_value)
|
|
|
|
{
|
|
|
|
my_error(ER_MULTIPLE_DEF_CONST_IN_LIST_PART_ERROR, MYF(0));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-03-07 12:25:08 +01:00
|
|
|
}
|
|
|
|
Lex->part_info->curr_part_elem->has_null_value= TRUE;
|
|
|
|
}
|
2007-04-04 16:26:32 +02:00
|
|
|
else if (part_expr->result_type() != INT_RESULT)
|
2005-07-22 20:47:05 +02:00
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_INCONSISTENT_TYPE_OF_FUNCTIONS_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-22 20:47:05 +02:00
|
|
|
}
|
2006-03-07 12:25:08 +01:00
|
|
|
$$= value_ptr;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
2005-08-19 16:26:05 +02:00
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
opt_sub_partition:
|
2006-03-13 11:36:02 +01:00
|
|
|
/* empty */
|
|
|
|
{
|
|
|
|
if (Lex->part_info->no_subparts != 0 &&
|
|
|
|
!Lex->part_info->use_default_subpartitions)
|
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_PARTITION_WRONG_NO_SUBPART_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-03-13 11:36:02 +01:00
|
|
|
}
|
|
|
|
}
|
2005-07-18 13:31:02 +02:00
|
|
|
| '(' sub_part_list ')'
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
partition_info *part_info= lex->part_info;
|
|
|
|
if (part_info->no_subparts != 0)
|
|
|
|
{
|
|
|
|
if (part_info->no_subparts !=
|
|
|
|
part_info->count_curr_subparts)
|
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_PARTITION_WRONG_NO_SUBPART_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (part_info->count_curr_subparts > 0)
|
|
|
|
{
|
2006-03-13 11:36:02 +01:00
|
|
|
if (part_info->partitions.elements > 1)
|
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_PARTITION_WRONG_NO_SUBPART_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-03-13 11:36:02 +01:00
|
|
|
}
|
2005-07-18 13:31:02 +02:00
|
|
|
part_info->no_subparts= part_info->count_curr_subparts;
|
|
|
|
}
|
|
|
|
part_info->count_curr_subparts= 0;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
sub_part_list:
|
|
|
|
sub_part_definition {}
|
2005-08-19 16:26:05 +02:00
|
|
|
| sub_part_list ',' sub_part_definition {}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
sub_part_definition:
|
|
|
|
SUBPARTITION_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
partition_info *part_info= lex->part_info;
|
2006-07-05 18:57:23 +02:00
|
|
|
partition_element *curr_part= part_info->current_partition;
|
|
|
|
partition_element *sub_p_elem= new partition_element(curr_part);
|
|
|
|
if (!sub_p_elem ||
|
|
|
|
curr_part->subpartitions.push_back(sub_p_elem))
|
2005-07-18 13:31:02 +02:00
|
|
|
{
|
2006-01-17 08:40:00 +01:00
|
|
|
mem_alloc_error(sizeof(partition_element));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-18 13:31:02 +02:00
|
|
|
}
|
2006-07-05 18:57:23 +02:00
|
|
|
part_info->curr_part_elem= sub_p_elem;
|
2005-07-18 13:31:02 +02:00
|
|
|
part_info->use_default_subpartitions= FALSE;
|
2006-01-17 08:40:00 +01:00
|
|
|
part_info->use_default_no_subpartitions= FALSE;
|
2005-07-18 13:31:02 +02:00
|
|
|
part_info->count_curr_subparts++;
|
|
|
|
}
|
2005-08-19 16:26:05 +02:00
|
|
|
sub_name opt_part_options {}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
sub_name:
|
|
|
|
ident_or_text
|
2005-08-19 16:26:05 +02:00
|
|
|
{ Lex->part_info->curr_part_elem->partition_name= $1.str; }
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
opt_part_options:
|
|
|
|
/* empty */ {}
|
2005-08-19 16:26:05 +02:00
|
|
|
| opt_part_option_list {}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
opt_part_option_list:
|
|
|
|
opt_part_option_list opt_part_option {}
|
2005-08-19 16:26:05 +02:00
|
|
|
| opt_part_option {}
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
opt_part_option:
|
|
|
|
TABLESPACE opt_equal ident_or_text
|
|
|
|
{ Lex->part_info->curr_part_elem->tablespace_name= $3.str; }
|
|
|
|
| opt_storage ENGINE_SYM opt_equal storage_engines
|
2005-09-20 16:29:59 +02:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->part_info->curr_part_elem->engine_type= $4;
|
|
|
|
lex->part_info->default_engine_type= $4;
|
|
|
|
}
|
2006-08-07 18:02:28 +02:00
|
|
|
| NODEGROUP_SYM opt_equal real_ulong_num
|
2006-11-30 02:40:42 +01:00
|
|
|
{ Lex->part_info->curr_part_elem->nodegroup_id= (uint16) $3; }
|
2006-08-07 18:02:28 +02:00
|
|
|
| MAX_ROWS opt_equal real_ulonglong_num
|
2006-11-30 02:40:42 +01:00
|
|
|
{ Lex->part_info->curr_part_elem->part_max_rows= (ha_rows) $3; }
|
2006-08-07 18:02:28 +02:00
|
|
|
| MIN_ROWS opt_equal real_ulonglong_num
|
2006-11-30 02:40:42 +01:00
|
|
|
{ Lex->part_info->curr_part_elem->part_min_rows= (ha_rows) $3; }
|
2005-07-18 13:31:02 +02:00
|
|
|
| DATA_SYM DIRECTORY_SYM opt_equal TEXT_STRING_sys
|
|
|
|
{ Lex->part_info->curr_part_elem->data_file_name= $4.str; }
|
|
|
|
| INDEX_SYM DIRECTORY_SYM opt_equal TEXT_STRING_sys
|
|
|
|
{ Lex->part_info->curr_part_elem->index_file_name= $4.str; }
|
|
|
|
| COMMENT_SYM opt_equal TEXT_STRING_sys
|
2005-08-19 16:26:05 +02:00
|
|
|
{ Lex->part_info->curr_part_elem->part_comment= $3.str; }
|
|
|
|
;
|
2005-07-18 13:31:02 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
End of partition parser part
|
|
|
|
*/
|
|
|
|
|
2003-06-30 22:24:03 +02:00
|
|
|
create_select:
|
2003-06-17 15:20:07 +02:00
|
|
|
SELECT_SYM
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
2005-02-15 11:02:01 +01:00
|
|
|
lex->lock_option= using_update_log ? TL_READ_NO_INSERT : TL_READ;
|
2003-07-03 10:55:36 +02:00
|
|
|
if (lex->sql_command == SQLCOM_INSERT)
|
|
|
|
lex->sql_command= SQLCOM_INSERT_SELECT;
|
|
|
|
else if (lex->sql_command == SQLCOM_REPLACE)
|
|
|
|
lex->sql_command= SQLCOM_REPLACE_SELECT;
|
2004-11-12 04:01:46 +01:00
|
|
|
/*
|
|
|
|
The following work only with the local list, the global list
|
|
|
|
is created correctly in this case
|
|
|
|
*/
|
2003-08-20 16:35:12 +02:00
|
|
|
lex->current_select->table_list.save_and_clear(&lex->save_list);
|
2001-06-15 04:03:15 +02:00
|
|
|
mysql_init_select(lex);
|
2004-08-13 09:01:30 +02:00
|
|
|
lex->current_select->parsing_place= SELECT_LIST;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2003-05-17 09:05:07 +02:00
|
|
|
select_options select_item_list
|
|
|
|
{
|
2004-08-13 09:01:30 +02:00
|
|
|
Select->parsing_place= NO_MATTER;
|
2003-05-17 09:05:07 +02:00
|
|
|
}
|
2003-08-11 21:44:43 +02:00
|
|
|
opt_select_from
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
The following work only with the local list, the global list
|
|
|
|
is created correctly in this case
|
|
|
|
*/
|
|
|
|
Lex->current_select->table_list.push_front(&Lex->save_list);
|
|
|
|
}
|
2003-08-11 21:44:43 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2000-10-14 02:16:35 +02:00
|
|
|
opt_as:
|
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| AS {};
|
2000-10-14 02:16:35 +02:00
|
|
|
|
2003-01-09 12:37:59 +01:00
|
|
|
opt_create_database_options:
|
|
|
|
/* empty */ {}
|
|
|
|
| create_database_options {};
|
|
|
|
|
|
|
|
create_database_options:
|
|
|
|
create_database_option {}
|
|
|
|
| create_database_options create_database_option {};
|
|
|
|
|
|
|
|
create_database_option:
|
2004-08-27 17:48:19 +02:00
|
|
|
default_collation {}
|
|
|
|
| default_charset {};
|
2003-01-09 12:37:59 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
opt_table_options:
|
2000-08-21 23:39:08 +02:00
|
|
|
/* empty */ { $$= 0; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| table_options { $$= $1;};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
table_options:
|
|
|
|
table_option { $$=$1; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| table_option table_options { $$= $1 | $2; };
|
2000-08-21 23:39:08 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
table_option:
|
2002-04-16 01:09:30 +02:00
|
|
|
TEMPORARY { $$=HA_LEX_CREATE_TMP_TABLE; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_if_not_exists:
|
2000-08-21 23:39:08 +02:00
|
|
|
/* empty */ { $$= 0; }
|
2004-11-17 16:49:10 +01:00
|
|
|
| IF not EXISTS { $$=HA_LEX_CREATE_IF_NOT_EXISTS; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_create_table_options:
|
|
|
|
/* empty */
|
2002-04-16 01:09:30 +02:00
|
|
|
| create_table_options;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-10-23 16:18:54 +02:00
|
|
|
create_table_options_space_separated:
|
|
|
|
create_table_option
|
|
|
|
| create_table_option create_table_options_space_separated;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
create_table_options:
|
|
|
|
create_table_option
|
2002-12-07 12:35:57 +01:00
|
|
|
| create_table_option create_table_options
|
2002-10-23 16:18:54 +02:00
|
|
|
| create_table_option ',' create_table_options;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
create_table_option:
|
2004-11-12 04:01:46 +01:00
|
|
|
ENGINE_SYM opt_equal storage_engines { Lex->create_info.db_type= $3; Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE; }
|
2006-03-01 21:36:05 +01:00
|
|
|
| TYPE_SYM opt_equal storage_engines
|
|
|
|
{
|
|
|
|
Lex->create_info.db_type= $3;
|
|
|
|
WARN_DEPRECATED(yythd, "5.2", "TYPE=storage_engine",
|
|
|
|
"'ENGINE=storage_engine'");
|
|
|
|
Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE;
|
|
|
|
}
|
2002-11-28 17:25:41 +01:00
|
|
|
| MAX_ROWS opt_equal ulonglong_num { Lex->create_info.max_rows= $3; Lex->create_info.used_fields|= HA_CREATE_USED_MAX_ROWS;}
|
|
|
|
| MIN_ROWS opt_equal ulonglong_num { Lex->create_info.min_rows= $3; Lex->create_info.used_fields|= HA_CREATE_USED_MIN_ROWS;}
|
2005-04-04 00:50:05 +02:00
|
|
|
| AVG_ROW_LENGTH opt_equal ulong_num { Lex->create_info.avg_row_length=$3; Lex->create_info.used_fields|= HA_CREATE_USED_AVG_ROW_LENGTH;}
|
2004-11-12 04:01:46 +01:00
|
|
|
| PASSWORD opt_equal TEXT_STRING_sys { Lex->create_info.password=$3.str; Lex->create_info.used_fields|= HA_CREATE_USED_PASSWORD; }
|
2006-06-29 15:39:34 +02:00
|
|
|
| COMMENT_SYM opt_equal TEXT_STRING_sys { Lex->create_info.comment=$3; Lex->create_info.used_fields|= HA_CREATE_USED_COMMENT; }
|
2002-11-28 17:25:41 +01:00
|
|
|
| AUTO_INC opt_equal ulonglong_num { Lex->create_info.auto_increment_value=$3; Lex->create_info.used_fields|= HA_CREATE_USED_AUTO;}
|
2005-08-29 17:24:07 +02:00
|
|
|
| PACK_KEYS_SYM opt_equal ulong_num
|
|
|
|
{
|
|
|
|
switch($3) {
|
|
|
|
case 0:
|
|
|
|
Lex->create_info.table_options|= HA_OPTION_NO_PACK_KEYS;
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
Lex->create_info.table_options|= HA_OPTION_PACK_KEYS;
|
|
|
|
break;
|
|
|
|
default:
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2005-08-29 17:24:07 +02:00
|
|
|
}
|
|
|
|
Lex->create_info.used_fields|= HA_CREATE_USED_PACK_KEYS;
|
|
|
|
}
|
|
|
|
| PACK_KEYS_SYM opt_equal DEFAULT
|
|
|
|
{
|
|
|
|
Lex->create_info.table_options&=
|
|
|
|
~(HA_OPTION_PACK_KEYS | HA_OPTION_NO_PACK_KEYS);
|
|
|
|
Lex->create_info.used_fields|= HA_CREATE_USED_PACK_KEYS;
|
|
|
|
}
|
2005-04-04 00:50:05 +02:00
|
|
|
| CHECKSUM_SYM opt_equal ulong_num { Lex->create_info.table_options|= $3 ? HA_OPTION_CHECKSUM : HA_OPTION_NO_CHECKSUM; Lex->create_info.used_fields|= HA_CREATE_USED_CHECKSUM; }
|
|
|
|
| DELAY_KEY_WRITE_SYM opt_equal ulong_num { Lex->create_info.table_options|= $3 ? HA_OPTION_DELAY_KEY_WRITE : HA_OPTION_NO_DELAY_KEY_WRITE; Lex->create_info.used_fields|= HA_CREATE_USED_DELAY_KEY_WRITE; }
|
2004-11-12 04:01:46 +01:00
|
|
|
| ROW_FORMAT_SYM opt_equal row_types { Lex->create_info.row_type= $3; Lex->create_info.used_fields|= HA_CREATE_USED_ROW_FORMAT; }
|
2002-11-28 17:25:41 +01:00
|
|
|
| UNION_SYM opt_equal '(' table_list ')'
|
2000-09-14 01:39:07 +02:00
|
|
|
{
|
|
|
|
/* Move the union list to the merge_list */
|
|
|
|
LEX *lex=Lex;
|
2002-10-30 12:18:52 +01:00
|
|
|
TABLE_LIST *table_list= lex->select_lex.get_table_list();
|
|
|
|
lex->create_info.merge_list= lex->select_lex.table_list;
|
2000-09-14 01:39:07 +02:00
|
|
|
lex->create_info.merge_list.elements--;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->create_info.merge_list.first=
|
WL#3817: Simplify string / memory area types and make things more consistent (first part)
The following type conversions was done:
- Changed byte to uchar
- Changed gptr to uchar*
- Change my_string to char *
- Change my_size_t to size_t
- Change size_s to size_t
Removed declaration of byte, gptr, my_string, my_size_t and size_s.
Following function parameter changes was done:
- All string functions in mysys/strings was changed to use size_t
instead of uint for string lengths.
- All read()/write() functions changed to use size_t (including vio).
- All protocoll functions changed to use size_t instead of uint
- Functions that used a pointer to a string length was changed to use size_t*
- Changed malloc(), free() and related functions from using gptr to use void *
as this requires fewer casts in the code and is more in line with how the
standard functions work.
- Added extra length argument to dirname_part() to return the length of the
created string.
- Changed (at least) following functions to take uchar* as argument:
- db_dump()
- my_net_write()
- net_write_command()
- net_store_data()
- DBUG_DUMP()
- decimal2bin() & bin2decimal()
- Changed my_compress() and my_uncompress() to use size_t. Changed one
argument to my_uncompress() from a pointer to a value as we only return
one value (makes function easier to use).
- Changed type of 'pack_data' argument to packfrm() to avoid casts.
- Changed in readfrm() and writefrom(), ha_discover and handler::discover()
the type for argument 'frmdata' to uchar** to avoid casts.
- Changed most Field functions to use uchar* instead of char* (reduced a lot of
casts).
- Changed field->val_xxx(xxx, new_ptr) to take const pointers.
Other changes:
- Removed a lot of not needed casts
- Added a few new cast required by other changes
- Added some cast to my_multi_malloc() arguments for safety (as string lengths
needs to be uint, not size_t).
- Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
explicitely as this conflict was often hided by casting the function to
hash_get_key).
- Changed some buffers to memory regions to uchar* to avoid casts.
- Changed some string lengths from uint to size_t.
- Changed field->ptr to be uchar* instead of char*. This allowed us to
get rid of a lot of casts.
- Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
- Include zlib.h in some files as we needed declaration of crc32()
- Changed MY_FILE_ERROR to be (size_t) -1.
- Changed many variables to hold the result of my_read() / my_write() to be
size_t. This was needed to properly detect errors (which are
returned as (size_t) -1).
- Removed some very old VMS code
- Changed packfrm()/unpackfrm() to not be depending on uint size
(portability fix)
- Removed windows specific code to restore cursor position as this
causes slowdown on windows and we should not mix read() and pread()
calls anyway as this is not thread safe. Updated function comment to
reflect this. Changed function that depended on original behavior of
my_pwrite() to itself restore the cursor position (one such case).
- Added some missing checking of return value of malloc().
- Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
- Changed type of table_def::m_size from my_size_t to ulong to reflect that
m_size is the number of elements in the array, not a string/memory
length.
- Moved THD::max_row_length() to table.cc (as it's not depending on THD).
Inlined max_row_length_blob() into this function.
- More function comments
- Fixed some compiler warnings when compiled without partitions.
- Removed setting of LEX_STRING() arguments in declaration (portability fix).
- Some trivial indentation/variable name changes.
- Some trivial code simplifications:
- Replaced some calls to alloc_root + memcpy to use
strmake_root()/strdup_root().
- Changed some calls from memdup() to strmake() (Safety fix)
- Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
|
|
|
(uchar*) (table_list->next_local);
|
2002-10-30 12:18:52 +01:00
|
|
|
lex->select_lex.table_list.elements=1;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->select_lex.table_list.next=
|
WL#3817: Simplify string / memory area types and make things more consistent (first part)
The following type conversions was done:
- Changed byte to uchar
- Changed gptr to uchar*
- Change my_string to char *
- Change my_size_t to size_t
- Change size_s to size_t
Removed declaration of byte, gptr, my_string, my_size_t and size_s.
Following function parameter changes was done:
- All string functions in mysys/strings was changed to use size_t
instead of uint for string lengths.
- All read()/write() functions changed to use size_t (including vio).
- All protocoll functions changed to use size_t instead of uint
- Functions that used a pointer to a string length was changed to use size_t*
- Changed malloc(), free() and related functions from using gptr to use void *
as this requires fewer casts in the code and is more in line with how the
standard functions work.
- Added extra length argument to dirname_part() to return the length of the
created string.
- Changed (at least) following functions to take uchar* as argument:
- db_dump()
- my_net_write()
- net_write_command()
- net_store_data()
- DBUG_DUMP()
- decimal2bin() & bin2decimal()
- Changed my_compress() and my_uncompress() to use size_t. Changed one
argument to my_uncompress() from a pointer to a value as we only return
one value (makes function easier to use).
- Changed type of 'pack_data' argument to packfrm() to avoid casts.
- Changed in readfrm() and writefrom(), ha_discover and handler::discover()
the type for argument 'frmdata' to uchar** to avoid casts.
- Changed most Field functions to use uchar* instead of char* (reduced a lot of
casts).
- Changed field->val_xxx(xxx, new_ptr) to take const pointers.
Other changes:
- Removed a lot of not needed casts
- Added a few new cast required by other changes
- Added some cast to my_multi_malloc() arguments for safety (as string lengths
needs to be uint, not size_t).
- Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
explicitely as this conflict was often hided by casting the function to
hash_get_key).
- Changed some buffers to memory regions to uchar* to avoid casts.
- Changed some string lengths from uint to size_t.
- Changed field->ptr to be uchar* instead of char*. This allowed us to
get rid of a lot of casts.
- Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
- Include zlib.h in some files as we needed declaration of crc32()
- Changed MY_FILE_ERROR to be (size_t) -1.
- Changed many variables to hold the result of my_read() / my_write() to be
size_t. This was needed to properly detect errors (which are
returned as (size_t) -1).
- Removed some very old VMS code
- Changed packfrm()/unpackfrm() to not be depending on uint size
(portability fix)
- Removed windows specific code to restore cursor position as this
causes slowdown on windows and we should not mix read() and pread()
calls anyway as this is not thread safe. Updated function comment to
reflect this. Changed function that depended on original behavior of
my_pwrite() to itself restore the cursor position (one such case).
- Added some missing checking of return value of malloc().
- Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
- Changed type of table_def::m_size from my_size_t to ulong to reflect that
m_size is the number of elements in the array, not a string/memory
length.
- Moved THD::max_row_length() to table.cc (as it's not depending on THD).
Inlined max_row_length_blob() into this function.
- More function comments
- Fixed some compiler warnings when compiled without partitions.
- Removed setting of LEX_STRING() arguments in declaration (portability fix).
- Some trivial indentation/variable name changes.
- Some trivial code simplifications:
- Replaced some calls to alloc_root + memcpy to use
strmake_root()/strdup_root().
- Changed some calls from memdup() to strmake() (Safety fix)
- Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
|
|
|
(uchar**) &(table_list->next_local);
|
2004-11-12 04:01:46 +01:00
|
|
|
table_list->next_local= 0;
|
2001-03-06 14:24:08 +01:00
|
|
|
lex->create_info.used_fields|= HA_CREATE_USED_UNION;
|
2000-09-14 01:39:07 +02:00
|
|
|
}
|
2004-08-27 17:48:19 +02:00
|
|
|
| default_charset
|
|
|
|
| default_collation
|
2002-11-28 17:25:41 +01:00
|
|
|
| INSERT_METHOD opt_equal merge_insert_types { Lex->create_info.merge_insert_method= $3; Lex->create_info.used_fields|= HA_CREATE_USED_INSERT_METHOD;}
|
2004-11-12 04:01:46 +01:00
|
|
|
| DATA_SYM DIRECTORY_SYM opt_equal TEXT_STRING_sys { Lex->create_info.data_file_name= $4.str; Lex->create_info.used_fields|= HA_CREATE_USED_DATADIR; }
|
|
|
|
| INDEX_SYM DIRECTORY_SYM opt_equal TEXT_STRING_sys { Lex->create_info.index_file_name= $4.str; Lex->create_info.used_fields|= HA_CREATE_USED_INDEXDIR; }
|
2006-01-11 11:35:25 +01:00
|
|
|
| TABLESPACE ident {Lex->create_info.tablespace= $2.str;}
|
2006-12-19 23:20:43 +01:00
|
|
|
| STORAGE_SYM DISK_SYM {Lex->create_info.storage_media= HA_SM_DISK;}
|
|
|
|
| STORAGE_SYM MEMORY_SYM {Lex->create_info.storage_media= HA_SM_MEMORY;}
|
2005-09-13 03:02:17 +02:00
|
|
|
| CONNECTION_SYM opt_equal TEXT_STRING_sys { Lex->create_info.connect_string.str= $3.str; Lex->create_info.connect_string.length= $3.length; Lex->create_info.used_fields|= HA_CREATE_USED_CONNECTION; }
|
2006-05-03 14:59:17 +02:00
|
|
|
| KEY_BLOCK_SIZE opt_equal ulong_num
|
|
|
|
{
|
|
|
|
Lex->create_info.used_fields|= HA_CREATE_USED_KEY_BLOCK_SIZE;
|
|
|
|
Lex->create_info.key_block_size= $3;
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2004-08-27 17:48:19 +02:00
|
|
|
default_charset:
|
|
|
|
opt_default charset opt_equal charset_name_or_default
|
|
|
|
{
|
|
|
|
HA_CREATE_INFO *cinfo= &Lex->create_info;
|
|
|
|
if ((cinfo->used_fields & HA_CREATE_USED_DEFAULT_CHARSET) &&
|
|
|
|
cinfo->default_table_charset && $4 &&
|
|
|
|
!my_charset_same(cinfo->default_table_charset,$4))
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_CONFLICTING_DECLARATIONS, MYF(0),
|
|
|
|
"CHARACTER SET ", cinfo->default_table_charset->csname,
|
|
|
|
"CHARACTER SET ", $4->csname);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-08-27 17:48:19 +02:00
|
|
|
}
|
|
|
|
Lex->create_info.default_table_charset= $4;
|
|
|
|
Lex->create_info.used_fields|= HA_CREATE_USED_DEFAULT_CHARSET;
|
|
|
|
};
|
|
|
|
|
|
|
|
default_collation:
|
|
|
|
opt_default COLLATE_SYM opt_equal collation_name_or_default
|
|
|
|
{
|
|
|
|
HA_CREATE_INFO *cinfo= &Lex->create_info;
|
|
|
|
if ((cinfo->used_fields & HA_CREATE_USED_DEFAULT_CHARSET) &&
|
|
|
|
cinfo->default_table_charset && $4 &&
|
|
|
|
!my_charset_same(cinfo->default_table_charset,$4))
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_COLLATION_CHARSET_MISMATCH, MYF(0),
|
|
|
|
$4->name, cinfo->default_table_charset->csname);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-08-27 17:48:19 +02:00
|
|
|
}
|
|
|
|
Lex->create_info.default_table_charset= $4;
|
|
|
|
Lex->create_info.used_fields|= HA_CREATE_USED_DEFAULT_CHARSET;
|
|
|
|
};
|
|
|
|
|
2003-12-17 23:52:03 +01:00
|
|
|
storage_engines:
|
2003-12-02 21:23:13 +01:00
|
|
|
ident_or_text
|
|
|
|
{
|
2007-04-16 18:16:17 +02:00
|
|
|
plugin_ref plugin= ha_resolve_by_name(YYTHD, &$1);
|
2007-04-16 10:37:50 +02:00
|
|
|
|
2007-04-16 18:16:17 +02:00
|
|
|
if (plugin)
|
2007-03-02 17:43:45 +01:00
|
|
|
$$= plugin_data(plugin, handlerton*);
|
|
|
|
else
|
2006-05-28 14:51:01 +02:00
|
|
|
{
|
Bug#24392 (SHOW ENGINE MUTEX STATUS is a synonym for SHOW INNODB STATUS)
Before this fix, the command SHOW ENGINE <name> STATUS would:
- print a warning if the engine name is unknown,
- proceed and implement the same behavior as SHOW ENGINE ALL STATUS,
and list the status of all the storage engines registered.
In particular, this behavior caused confusion about the command :
SHOW ENGINE MUTEX STATUS, which as a side effect would print the status
of the innodb engine when that engine is registered.
Also, before this fix, every time an unknown engine name was substituted by
the default engine (which happen unless SQL_MODE NO_ENGINE_SUBSTITUTION is
set), a malformed warning was raised.
For example, the command ALTER TABLE T1 ENGINE = X would print :
Warnings:
Error 1286 Unknown table engine 'X'
With this fix:
SHOW ENGINE <name> STATUS|LOGS|MUTEX
always fails with an error when the engine <name> is unknown.
For other commands, warnings about unknown engines are raised as:
Warnings:
Warning 1286 Unknown table engine 'X'
In other words, engine substitution never affect the SHOW ENGINE command,
since this would lead to very confusing results.
2007-01-23 23:14:08 +01:00
|
|
|
if (YYTHD->variables.sql_mode & MODE_NO_ENGINE_SUBSTITUTION)
|
2007-04-16 10:37:50 +02:00
|
|
|
{
|
|
|
|
my_error(ER_UNKNOWN_STORAGE_ENGINE, MYF(0), $1.str);
|
|
|
|
MYSQL_YYABORT;
|
|
|
|
}
|
2007-04-16 18:16:17 +02:00
|
|
|
$$= 0;
|
Bug#24392 (SHOW ENGINE MUTEX STATUS is a synonym for SHOW INNODB STATUS)
Before this fix, the command SHOW ENGINE <name> STATUS would:
- print a warning if the engine name is unknown,
- proceed and implement the same behavior as SHOW ENGINE ALL STATUS,
and list the status of all the storage engines registered.
In particular, this behavior caused confusion about the command :
SHOW ENGINE MUTEX STATUS, which as a side effect would print the status
of the innodb engine when that engine is registered.
Also, before this fix, every time an unknown engine name was substituted by
the default engine (which happen unless SQL_MODE NO_ENGINE_SUBSTITUTION is
set), a malformed warning was raised.
For example, the command ALTER TABLE T1 ENGINE = X would print :
Warnings:
Error 1286 Unknown table engine 'X'
With this fix:
SHOW ENGINE <name> STATUS|LOGS|MUTEX
always fails with an error when the engine <name> is unknown.
For other commands, warnings about unknown engines are raised as:
Warnings:
Warning 1286 Unknown table engine 'X'
In other words, engine substitution never affect the SHOW ENGINE command,
since this would lead to very confusing results.
2007-01-23 23:14:08 +01:00
|
|
|
push_warning_printf(YYTHD, MYSQL_ERROR::WARN_LEVEL_WARN,
|
2006-05-28 14:51:01 +02:00
|
|
|
ER_UNKNOWN_STORAGE_ENGINE,
|
2007-04-16 18:16:17 +02:00
|
|
|
ER(ER_UNKNOWN_STORAGE_ENGINE),
|
|
|
|
$1.str);
|
2006-05-28 14:51:01 +02:00
|
|
|
}
|
2007-04-16 18:16:17 +02:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2007-04-16 10:37:50 +02:00
|
|
|
known_storage_engines:
|
2007-03-02 17:43:45 +01:00
|
|
|
ident_or_text
|
|
|
|
{
|
|
|
|
plugin_ref plugin;
|
|
|
|
if ((plugin= ha_resolve_by_name(YYTHD, &$1)))
|
|
|
|
$$= plugin_data(plugin, handlerton*);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
my_error(ER_UNKNOWN_STORAGE_ENGINE, MYF(0), $1.str);
|
2007-04-16 10:37:50 +02:00
|
|
|
MYSQL_YYABORT;
|
2007-03-02 17:43:45 +01:00
|
|
|
}
|
2007-04-16 10:37:50 +02:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
row_types:
|
|
|
|
DEFAULT { $$= ROW_TYPE_DEFAULT; }
|
|
|
|
| FIXED_SYM { $$= ROW_TYPE_FIXED; }
|
|
|
|
| DYNAMIC_SYM { $$= ROW_TYPE_DYNAMIC; }
|
2005-01-07 15:43:27 +01:00
|
|
|
| COMPRESSED_SYM { $$= ROW_TYPE_COMPRESSED; }
|
|
|
|
| REDUNDANT_SYM { $$= ROW_TYPE_REDUNDANT; }
|
|
|
|
| COMPACT_SYM { $$= ROW_TYPE_COMPACT; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-09-22 16:40:57 +02:00
|
|
|
merge_insert_types:
|
|
|
|
NO_SYM { $$= MERGE_INSERT_DISABLED; }
|
|
|
|
| FIRST_SYM { $$= MERGE_INSERT_TO_FIRST; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| LAST_SYM { $$= MERGE_INSERT_TO_LAST; };
|
2001-09-22 16:40:57 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
opt_select_from:
|
2002-11-28 17:25:41 +01:00
|
|
|
opt_limit_clause {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| select_from select_lock_type;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
udf_func_type:
|
2003-09-03 11:34:32 +02:00
|
|
|
/* empty */ { $$ = UDFTYPE_FUNCTION; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| AGGREGATE_SYM { $$ = UDFTYPE_AGGREGATE; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
udf_type:
|
|
|
|
STRING_SYM {$$ = (int) STRING_RESULT; }
|
|
|
|
| REAL {$$ = (int) REAL_RESULT; }
|
2005-02-08 23:50:45 +01:00
|
|
|
| DECIMAL_SYM {$$ = (int) DECIMAL_RESULT; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| INT_SYM {$$ = (int) INT_RESULT; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
field_list:
|
|
|
|
field_list_item
|
2002-04-16 01:09:30 +02:00
|
|
|
| field_list ',' field_list_item;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
field_list_item:
|
2003-02-26 00:03:47 +01:00
|
|
|
column_def
|
2003-02-22 01:07:17 +01:00
|
|
|
| key_def
|
|
|
|
;
|
|
|
|
|
|
|
|
column_def:
|
2004-04-28 17:14:53 +02:00
|
|
|
field_spec opt_check_constraint
|
2000-07-31 21:29:14 +02:00
|
|
|
| field_spec references
|
|
|
|
{
|
|
|
|
Lex->col_list.empty(); /* Alloced by sql_alloc */
|
|
|
|
}
|
2003-02-26 00:03:47 +01:00
|
|
|
;
|
2003-02-22 01:07:17 +01:00
|
|
|
|
|
|
|
key_def:
|
2006-05-03 14:59:17 +02:00
|
|
|
key_type opt_ident key_alg '(' key_list ')' key_options
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
2006-05-03 18:40:52 +02:00
|
|
|
if ($1 != Key::FULLTEXT && lex->key_create_info.parser_name.str)
|
2005-11-06 13:13:06 +01:00
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-11-06 13:13:06 +01:00
|
|
|
}
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
Key *key= new Key($1, $2, &lex->key_create_info, 0,
|
|
|
|
lex->col_list);
|
|
|
|
lex->alter_info.key_list.push_back(key);
|
2001-06-15 04:03:15 +02:00
|
|
|
lex->col_list.empty(); /* Alloced by sql_alloc */
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2006-05-03 14:59:17 +02:00
|
|
|
| opt_constraint constraint_key_type opt_ident key_alg
|
|
|
|
'(' key_list ')' key_options
|
2003-12-02 16:06:24 +01:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2006-05-03 14:59:17 +02:00
|
|
|
const char *key_name= $3 ? $3 : $1;
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
Key *key= new Key($2, key_name, &lex->key_create_info, 0,
|
|
|
|
lex->col_list);
|
|
|
|
lex->alter_info.key_list.push_back(key);
|
2003-12-02 16:06:24 +01:00
|
|
|
lex->col_list.empty(); /* Alloced by sql_alloc */
|
|
|
|
}
|
2000-11-13 22:55:10 +01:00
|
|
|
| opt_constraint FOREIGN KEY_SYM opt_ident '(' key_list ')' references
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2002-06-02 20:22:20 +02:00
|
|
|
LEX *lex=Lex;
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
const char *key_name= $4 ? $4 : $1;
|
2007-06-10 12:43:57 +02:00
|
|
|
Key *key= new Foreign_key(key_name, lex->col_list,
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
$8,
|
|
|
|
lex->ref_list,
|
|
|
|
lex->fk_delete_opt,
|
|
|
|
lex->fk_update_opt,
|
|
|
|
lex->fk_match_option);
|
|
|
|
lex->alter_info.key_list.push_back(key);
|
|
|
|
key= new Key(Key::MULTIPLE, key_name,
|
|
|
|
&default_key_create_info, 1,
|
|
|
|
lex->col_list);
|
|
|
|
lex->alter_info.key_list.push_back(key);
|
2002-06-02 20:22:20 +02:00
|
|
|
lex->col_list.empty(); /* Alloced by sql_alloc */
|
2006-03-30 20:55:54 +02:00
|
|
|
/* Only used for ALTER TABLE. Ignored otherwise. */
|
|
|
|
lex->alter_info.flags|= ALTER_FOREIGN_KEY;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2004-04-28 17:14:53 +02:00
|
|
|
| constraint opt_check_constraint
|
|
|
|
{
|
|
|
|
Lex->col_list.empty(); /* Alloced by sql_alloc */
|
|
|
|
}
|
2002-11-24 14:47:19 +01:00
|
|
|
| opt_constraint check_constraint
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
|
|
|
Lex->col_list.empty(); /* Alloced by sql_alloc */
|
2002-11-24 14:47:19 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2004-04-28 17:14:53 +02:00
|
|
|
opt_check_constraint:
|
2002-11-24 14:47:19 +01:00
|
|
|
/* empty */
|
2004-04-28 17:14:53 +02:00
|
|
|
| check_constraint
|
|
|
|
;
|
|
|
|
|
|
|
|
check_constraint:
|
|
|
|
CHECK_SYM expr
|
2002-11-24 14:47:19 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_constraint:
|
2003-12-02 16:06:24 +01:00
|
|
|
/* empty */ { $$=(char*) 0; }
|
2004-05-05 20:24:21 +02:00
|
|
|
| constraint { $$= $1; }
|
|
|
|
;
|
|
|
|
|
|
|
|
constraint:
|
|
|
|
CONSTRAINT opt_ident { $$=$2; }
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
field_spec:
|
|
|
|
field_ident
|
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
2004-12-02 09:48:43 +01:00
|
|
|
lex->length=lex->dec=0; lex->type=0;
|
2004-04-02 08:12:53 +02:00
|
|
|
lex->default_value= lex->on_update_value= 0;
|
2005-01-16 13:16:23 +01:00
|
|
|
lex->comment=null_lex_str;
|
2002-06-19 18:21:30 +02:00
|
|
|
lex->charset=NULL;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
type opt_attribute
|
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
2007-04-03 13:13:27 +02:00
|
|
|
if (add_field_to_list(lex->thd, &$1, (enum enum_field_types) $3,
|
2001-06-15 04:03:15 +02:00
|
|
|
lex->length,lex->dec,lex->type,
|
2004-04-02 08:12:53 +02:00
|
|
|
lex->default_value, lex->on_update_value,
|
2005-01-16 13:16:23 +01:00
|
|
|
&lex->comment,
|
2004-12-02 09:48:43 +01:00
|
|
|
lex->change,&lex->interval_list,lex->charset,
|
2003-03-27 10:09:09 +01:00
|
|
|
lex->uint_geom_type))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
type:
|
2002-11-21 01:07:14 +01:00
|
|
|
int_type opt_len field_options { $$=$1; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| real_type opt_precision field_options { $$=$1; }
|
2006-12-02 02:26:52 +01:00
|
|
|
| FLOAT_SYM float_options field_options { $$=MYSQL_TYPE_FLOAT; }
|
2004-12-17 15:06:05 +01:00
|
|
|
| BIT_SYM { Lex->length= (char*) "1";
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_BIT; }
|
2004-12-17 15:06:05 +01:00
|
|
|
| BIT_SYM '(' NUM ')' { Lex->length= $3.str;
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_BIT; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| BOOL_SYM { Lex->length=(char*) "1";
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_TINY; }
|
2002-12-01 13:59:06 +01:00
|
|
|
| BOOLEAN_SYM { Lex->length=(char*) "1";
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_TINY; }
|
2002-09-12 16:36:22 +02:00
|
|
|
| char '(' NUM ')' opt_binary { Lex->length=$3.str;
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_STRING; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| char opt_binary { Lex->length=(char*) "1";
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_STRING; }
|
2005-08-27 08:26:14 +02:00
|
|
|
| nchar '(' NUM ')' opt_bin_mod { Lex->length=$3.str;
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_STRING;
|
2003-03-21 08:21:01 +01:00
|
|
|
Lex->charset=national_charset_info; }
|
2005-08-27 08:26:14 +02:00
|
|
|
| nchar opt_bin_mod { Lex->length=(char*) "1";
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_STRING;
|
2003-03-21 08:21:01 +01:00
|
|
|
Lex->charset=national_charset_info; }
|
2002-11-29 16:17:52 +01:00
|
|
|
| BINARY '(' NUM ')' { Lex->length=$3.str;
|
2003-01-29 14:31:20 +01:00
|
|
|
Lex->charset=&my_charset_bin;
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_STRING; }
|
2004-11-16 09:05:13 +01:00
|
|
|
| BINARY { Lex->length= (char*) "1";
|
|
|
|
Lex->charset=&my_charset_bin;
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_STRING; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| varchar '(' NUM ')' opt_binary { Lex->length=$3.str;
|
2004-12-06 01:00:37 +01:00
|
|
|
$$= MYSQL_TYPE_VARCHAR; }
|
2005-08-27 08:26:14 +02:00
|
|
|
| nvarchar '(' NUM ')' opt_bin_mod { Lex->length=$3.str;
|
2004-12-06 01:00:37 +01:00
|
|
|
$$= MYSQL_TYPE_VARCHAR;
|
2003-03-21 08:21:01 +01:00
|
|
|
Lex->charset=national_charset_info; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| VARBINARY '(' NUM ')' { Lex->length=$3.str;
|
2003-01-29 14:31:20 +01:00
|
|
|
Lex->charset=&my_charset_bin;
|
2004-12-06 01:00:37 +01:00
|
|
|
$$= MYSQL_TYPE_VARCHAR; }
|
2006-12-02 02:26:52 +01:00
|
|
|
| YEAR_SYM opt_len field_options { $$=MYSQL_TYPE_YEAR; }
|
|
|
|
| DATE_SYM { $$=MYSQL_TYPE_DATE; }
|
|
|
|
| TIME_SYM { $$=MYSQL_TYPE_TIME; }
|
2005-01-11 12:26:40 +01:00
|
|
|
| TIMESTAMP opt_len
|
2002-11-20 20:44:32 +01:00
|
|
|
{
|
2003-10-15 11:50:36 +02:00
|
|
|
if (YYTHD->variables.sql_mode & MODE_MAXDB)
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_DATETIME;
|
2002-11-20 20:44:32 +01:00
|
|
|
else
|
2004-10-01 16:54:06 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
Unlike other types TIMESTAMP fields are NOT NULL by default.
|
|
|
|
*/
|
|
|
|
Lex->type|= NOT_NULL_FLAG;
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_TIMESTAMP;
|
2004-10-01 16:54:06 +02:00
|
|
|
}
|
2002-11-20 20:44:32 +01:00
|
|
|
}
|
2006-12-02 02:26:52 +01:00
|
|
|
| DATETIME { $$=MYSQL_TYPE_DATETIME; }
|
2003-01-29 14:31:20 +01:00
|
|
|
| TINYBLOB { Lex->charset=&my_charset_bin;
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_TINY_BLOB; }
|
2003-01-29 14:31:20 +01:00
|
|
|
| BLOB_SYM opt_len { Lex->charset=&my_charset_bin;
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_BLOB; }
|
2004-10-20 03:04:37 +02:00
|
|
|
| spatial_type
|
|
|
|
{
|
2004-01-15 18:06:22 +01:00
|
|
|
#ifdef HAVE_SPATIAL
|
2004-10-20 03:04:37 +02:00
|
|
|
Lex->charset=&my_charset_bin;
|
|
|
|
Lex->uint_geom_type= (uint)$1;
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_GEOMETRY;
|
2004-01-15 18:06:22 +01:00
|
|
|
#else
|
2005-02-19 10:51:49 +01:00
|
|
|
my_error(ER_FEATURE_DISABLED, MYF(0),
|
2004-11-13 18:35:51 +01:00
|
|
|
sym_group_geom.name, sym_group_geom.needed_define);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-01-15 18:06:22 +01:00
|
|
|
#endif
|
2004-10-20 03:04:37 +02:00
|
|
|
}
|
2003-01-29 14:31:20 +01:00
|
|
|
| MEDIUMBLOB { Lex->charset=&my_charset_bin;
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_MEDIUM_BLOB; }
|
2003-01-29 14:31:20 +01:00
|
|
|
| LONGBLOB { Lex->charset=&my_charset_bin;
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_LONG_BLOB; }
|
2003-01-29 14:31:20 +01:00
|
|
|
| LONG_SYM VARBINARY { Lex->charset=&my_charset_bin;
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_MEDIUM_BLOB; }
|
|
|
|
| LONG_SYM varchar opt_binary { $$=MYSQL_TYPE_MEDIUM_BLOB; }
|
|
|
|
| TINYTEXT opt_binary { $$=MYSQL_TYPE_TINY_BLOB; }
|
|
|
|
| TEXT_SYM opt_len opt_binary { $$=MYSQL_TYPE_BLOB; }
|
|
|
|
| MEDIUMTEXT opt_binary { $$=MYSQL_TYPE_MEDIUM_BLOB; }
|
|
|
|
| LONGTEXT opt_binary { $$=MYSQL_TYPE_LONG_BLOB; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| DECIMAL_SYM float_options field_options
|
2006-12-02 02:26:52 +01:00
|
|
|
{ $$=MYSQL_TYPE_NEWDECIMAL;}
|
2000-07-31 21:29:14 +02:00
|
|
|
| NUMERIC_SYM float_options field_options
|
2006-12-02 02:26:52 +01:00
|
|
|
{ $$=MYSQL_TYPE_NEWDECIMAL;}
|
2002-11-21 01:07:14 +01:00
|
|
|
| FIXED_SYM float_options field_options
|
2006-12-02 02:26:52 +01:00
|
|
|
{ $$=MYSQL_TYPE_NEWDECIMAL;}
|
2002-10-25 12:08:47 +02:00
|
|
|
| ENUM {Lex->interval_list.empty();} '(' string_list ')' opt_binary
|
2006-12-02 02:26:52 +01:00
|
|
|
{ $$=MYSQL_TYPE_ENUM; }
|
2002-10-25 12:08:47 +02:00
|
|
|
| SET { Lex->interval_list.empty();} '(' string_list ')' opt_binary
|
2006-12-02 02:26:52 +01:00
|
|
|
{ $$=MYSQL_TYPE_SET; }
|
|
|
|
| LONG_SYM opt_binary { $$=MYSQL_TYPE_MEDIUM_BLOB; }
|
2002-11-25 11:11:16 +01:00
|
|
|
| SERIAL_SYM
|
|
|
|
{
|
2006-12-02 02:26:52 +01:00
|
|
|
$$=MYSQL_TYPE_LONGLONG;
|
2002-11-25 11:11:16 +01:00
|
|
|
Lex->type|= (AUTO_INCREMENT_FLAG | NOT_NULL_FLAG | UNSIGNED_FLAG |
|
|
|
|
UNIQUE_FLAG);
|
|
|
|
}
|
2002-11-20 20:44:32 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2004-01-15 18:06:22 +01:00
|
|
|
spatial_type:
|
|
|
|
GEOMETRY_SYM { $$= Field::GEOM_GEOMETRY; }
|
|
|
|
| GEOMETRYCOLLECTION { $$= Field::GEOM_GEOMETRYCOLLECTION; }
|
2005-10-15 19:23:13 +02:00
|
|
|
| POINT_SYM { Lex->length= (char*)"21";
|
|
|
|
$$= Field::GEOM_POINT;
|
|
|
|
}
|
2004-01-15 18:06:22 +01:00
|
|
|
| MULTIPOINT { $$= Field::GEOM_MULTIPOINT; }
|
|
|
|
| LINESTRING { $$= Field::GEOM_LINESTRING; }
|
|
|
|
| MULTILINESTRING { $$= Field::GEOM_MULTILINESTRING; }
|
|
|
|
| POLYGON { $$= Field::GEOM_POLYGON; }
|
|
|
|
| MULTIPOLYGON { $$= Field::GEOM_MULTIPOLYGON; }
|
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
char:
|
|
|
|
CHAR_SYM {}
|
2003-03-20 16:31:01 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
nchar:
|
|
|
|
NCHAR_SYM {}
|
|
|
|
| NATIONAL_SYM CHAR_SYM {}
|
|
|
|
;
|
2000-08-21 23:39:08 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
varchar:
|
|
|
|
char VARYING {}
|
|
|
|
| VARCHAR {}
|
2003-03-20 17:04:21 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
nvarchar:
|
|
|
|
NATIONAL_SYM VARCHAR {}
|
2003-09-15 07:26:48 +02:00
|
|
|
| NVARCHAR_SYM {}
|
2003-03-20 17:04:21 +01:00
|
|
|
| NCHAR_SYM VARCHAR {}
|
|
|
|
| NATIONAL_SYM CHAR_SYM VARYING {}
|
|
|
|
| NCHAR_SYM VARYING {}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
int_type:
|
2006-12-02 02:26:52 +01:00
|
|
|
INT_SYM { $$=MYSQL_TYPE_LONG; }
|
|
|
|
| TINYINT { $$=MYSQL_TYPE_TINY; }
|
|
|
|
| SMALLINT { $$=MYSQL_TYPE_SHORT; }
|
|
|
|
| MEDIUMINT { $$=MYSQL_TYPE_INT24; }
|
|
|
|
| BIGINT { $$=MYSQL_TYPE_LONGLONG; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
real_type:
|
2003-01-16 01:04:50 +01:00
|
|
|
REAL { $$= YYTHD->variables.sql_mode & MODE_REAL_AS_FLOAT ?
|
2006-12-02 02:26:52 +01:00
|
|
|
MYSQL_TYPE_FLOAT : MYSQL_TYPE_DOUBLE; }
|
|
|
|
| DOUBLE_SYM { $$=MYSQL_TYPE_DOUBLE; }
|
|
|
|
| DOUBLE_SYM PRECISION { $$=MYSQL_TYPE_DOUBLE; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
float_options:
|
2005-02-08 23:50:45 +01:00
|
|
|
/* empty */ { Lex->dec=Lex->length= (char*)0; }
|
|
|
|
| '(' NUM ')' { Lex->length=$2.str; Lex->dec= (char*)0; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| precision {};
|
2001-06-15 04:03:15 +02:00
|
|
|
|
|
|
|
precision:
|
|
|
|
'(' NUM ',' NUM ')'
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->length=$2.str; lex->dec=$4.str;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
field_options:
|
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| field_opt_list {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
field_opt_list:
|
|
|
|
field_opt_list field_option {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| field_option {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
field_option:
|
2002-01-02 23:46:43 +01:00
|
|
|
SIGNED_SYM {}
|
2002-01-02 20:29:41 +01:00
|
|
|
| UNSIGNED { Lex->type|= UNSIGNED_FLAG;}
|
2002-04-16 01:09:30 +02:00
|
|
|
| ZEROFILL { Lex->type|= UNSIGNED_FLAG | ZEROFILL_FLAG; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_len:
|
2002-11-21 01:07:14 +01:00
|
|
|
/* empty */ { Lex->length=(char*) 0; } /* use default length */
|
|
|
|
| '(' NUM ')' { Lex->length= $2.str; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_precision:
|
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| precision {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_attribute:
|
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| opt_attribute_list {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_attribute_list:
|
|
|
|
opt_attribute_list attribute {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| attribute;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
attribute:
|
|
|
|
NULL_SYM { Lex->type&= ~ NOT_NULL_FLAG; }
|
2004-11-17 16:49:10 +01:00
|
|
|
| not NULL_SYM { Lex->type|= NOT_NULL_FLAG; }
|
2004-04-02 08:12:53 +02:00
|
|
|
| DEFAULT now_or_signed_literal { Lex->default_value=$2; }
|
|
|
|
| ON UPDATE_SYM NOW_SYM optional_braces
|
|
|
|
{ Lex->on_update_value= new Item_func_now_local(); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| AUTO_INC { Lex->type|= AUTO_INCREMENT_FLAG | NOT_NULL_FLAG; }
|
2002-11-20 20:44:32 +01:00
|
|
|
| SERIAL_SYM DEFAULT VALUE_SYM
|
2004-03-30 19:22:14 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->type|= AUTO_INCREMENT_FLAG | NOT_NULL_FLAG | UNIQUE_FLAG;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.flags|= ALTER_ADD_INDEX;
|
2004-03-30 19:22:14 +02:00
|
|
|
}
|
|
|
|
| opt_primary KEY_SYM
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->type|= PRI_KEY_FLAG | NOT_NULL_FLAG;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.flags|= ALTER_ADD_INDEX;
|
2004-03-30 19:22:14 +02:00
|
|
|
}
|
|
|
|
| UNIQUE_SYM
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->type|= UNIQUE_FLAG;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.flags|= ALTER_ADD_INDEX;
|
2004-03-30 19:22:14 +02:00
|
|
|
}
|
|
|
|
| UNIQUE_SYM KEY_SYM
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->type|= UNIQUE_KEY_FLAG;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.flags|= ALTER_ADD_INDEX;
|
2004-03-30 19:22:14 +02:00
|
|
|
}
|
2005-01-16 13:16:23 +01:00
|
|
|
| COMMENT_SYM TEXT_STRING_sys { Lex->comment= $2; }
|
2003-08-11 21:44:43 +02:00
|
|
|
| COLLATE_SYM collation_name
|
|
|
|
{
|
2003-03-16 14:19:24 +01:00
|
|
|
if (Lex->charset && !my_charset_same(Lex->charset,$2))
|
2003-03-02 11:47:56 +01:00
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_COLLATION_CHARSET_MISMATCH, MYF(0),
|
|
|
|
$2->name,Lex->charset->csname);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-03-02 11:47:56 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
Lex->charset=$2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2004-04-02 08:12:53 +02:00
|
|
|
now_or_signed_literal:
|
|
|
|
NOW_SYM optional_braces { $$= new Item_func_now_local(); }
|
|
|
|
| signed_literal { $$=$1; }
|
|
|
|
;
|
|
|
|
|
2003-03-05 13:43:10 +01:00
|
|
|
charset:
|
|
|
|
CHAR_SYM SET {}
|
|
|
|
| CHARSET {}
|
|
|
|
;
|
2002-11-25 11:11:16 +01:00
|
|
|
|
2002-09-12 16:36:22 +02:00
|
|
|
charset_name:
|
2003-03-05 09:37:39 +01:00
|
|
|
ident_or_text
|
2002-11-29 16:17:52 +01:00
|
|
|
{
|
2003-03-04 16:53:53 +01:00
|
|
|
if (!($$=get_charset_by_csname($1.str,MY_CS_PRIMARY,MYF(0))))
|
2002-06-20 15:47:55 +02:00
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_UNKNOWN_CHARACTER_SET, MYF(0), $1.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-06-20 15:47:55 +02:00
|
|
|
}
|
2003-03-18 07:02:57 +01:00
|
|
|
}
|
|
|
|
| BINARY { $$= &my_charset_bin; }
|
|
|
|
;
|
2002-06-20 15:47:55 +02:00
|
|
|
|
2002-09-12 16:36:22 +02:00
|
|
|
charset_name_or_default:
|
|
|
|
charset_name { $$=$1; }
|
|
|
|
| DEFAULT { $$=NULL; } ;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2007-02-28 14:06:57 +01:00
|
|
|
opt_load_data_charset:
|
|
|
|
/* Empty */ { $$= NULL; }
|
|
|
|
| charset charset_name_or_default { $$= $2; }
|
|
|
|
;
|
2003-04-05 15:56:15 +02:00
|
|
|
|
|
|
|
old_or_new_charset_name:
|
|
|
|
ident_or_text
|
|
|
|
{
|
|
|
|
if (!($$=get_charset_by_csname($1.str,MY_CS_PRIMARY,MYF(0))) &&
|
|
|
|
!($$=get_old_charset_by_name($1.str)))
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_UNKNOWN_CHARACTER_SET, MYF(0), $1.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-04-05 15:56:15 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
| BINARY { $$= &my_charset_bin; }
|
|
|
|
;
|
|
|
|
|
|
|
|
old_or_new_charset_name_or_default:
|
|
|
|
old_or_new_charset_name { $$=$1; }
|
|
|
|
| DEFAULT { $$=NULL; } ;
|
|
|
|
|
2003-01-09 12:37:59 +01:00
|
|
|
collation_name:
|
2003-03-05 09:37:39 +01:00
|
|
|
ident_or_text
|
2003-01-09 12:37:59 +01:00
|
|
|
{
|
|
|
|
if (!($$=get_charset_by_name($1.str,MYF(0))))
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_UNKNOWN_COLLATION, MYF(0), $1.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-01-09 12:37:59 +01:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2003-03-05 09:37:39 +01:00
|
|
|
opt_collate:
|
|
|
|
/* empty */ { $$=NULL; }
|
2003-04-05 15:56:15 +02:00
|
|
|
| COLLATE_SYM collation_name_or_default { $$=$2; }
|
2003-03-05 09:37:39 +01:00
|
|
|
;
|
|
|
|
|
2003-01-09 12:37:59 +01:00
|
|
|
collation_name_or_default:
|
|
|
|
collation_name { $$=$1; }
|
|
|
|
| DEFAULT { $$=NULL; } ;
|
|
|
|
|
2002-10-24 11:22:42 +02:00
|
|
|
opt_default:
|
|
|
|
/* empty */ {}
|
|
|
|
| DEFAULT {};
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
opt_binary:
|
2002-06-19 18:21:30 +02:00
|
|
|
/* empty */ { Lex->charset=NULL; }
|
2005-08-27 08:26:14 +02:00
|
|
|
| ASCII_SYM opt_bin_mod { Lex->charset=&my_charset_latin1; }
|
2003-01-29 14:31:20 +01:00
|
|
|
| BYTE_SYM { Lex->charset=&my_charset_bin; }
|
2005-08-27 08:26:14 +02:00
|
|
|
| UNICODE_SYM opt_bin_mod
|
|
|
|
{
|
|
|
|
if (!(Lex->charset=get_charset_by_csname("ucs2",
|
|
|
|
MY_CS_PRIMARY,MYF(0))))
|
|
|
|
{
|
|
|
|
my_error(ER_UNKNOWN_CHARACTER_SET, MYF(0), "ucs2");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-08-27 08:26:14 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
| charset charset_name opt_bin_mod { Lex->charset=$2; }
|
|
|
|
| BINARY opt_bin_charset { Lex->type|= BINCMP_FLAG; };
|
|
|
|
|
|
|
|
opt_bin_mod:
|
|
|
|
/* empty */ { }
|
|
|
|
| BINARY { Lex->type|= BINCMP_FLAG; };
|
|
|
|
|
|
|
|
opt_bin_charset:
|
2006-07-12 22:22:38 +02:00
|
|
|
/* empty */ { Lex->charset= NULL; }
|
2005-08-27 08:26:14 +02:00
|
|
|
| ASCII_SYM { Lex->charset=&my_charset_latin1; }
|
2002-12-19 06:38:25 +01:00
|
|
|
| UNICODE_SYM
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
if (!(Lex->charset=get_charset_by_csname("ucs2",
|
|
|
|
MY_CS_PRIMARY,MYF(0))))
|
2002-12-19 06:38:25 +01:00
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_UNKNOWN_CHARACTER_SET, MYF(0), "ucs2");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-12-19 06:38:25 +01:00
|
|
|
}
|
|
|
|
}
|
2003-03-05 13:43:10 +01:00
|
|
|
| charset charset_name { Lex->charset=$2; } ;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-11-25 11:11:16 +01:00
|
|
|
opt_primary:
|
|
|
|
/* empty */
|
|
|
|
| PRIMARY_SYM
|
2002-11-26 14:18:16 +01:00
|
|
|
;
|
2002-11-25 11:11:16 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
references:
|
2002-06-02 20:22:20 +02:00
|
|
|
REFERENCES table_ident
|
|
|
|
{
|
2002-12-04 23:14:51 +01:00
|
|
|
LEX *lex=Lex;
|
2002-06-02 20:22:20 +02:00
|
|
|
lex->fk_delete_opt= lex->fk_update_opt= lex->fk_match_option= 0;
|
|
|
|
lex->ref_list.empty();
|
|
|
|
}
|
|
|
|
opt_ref_list
|
|
|
|
{
|
|
|
|
$$=$2;
|
2002-06-03 11:59:31 +02:00
|
|
|
};
|
2002-12-04 23:14:51 +01:00
|
|
|
|
2002-06-02 20:22:20 +02:00
|
|
|
opt_ref_list:
|
2002-06-04 07:23:57 +02:00
|
|
|
/* empty */ opt_on_delete {}
|
2002-06-03 11:59:31 +02:00
|
|
|
| '(' ref_list ')' opt_on_delete {};
|
2002-06-02 20:22:20 +02:00
|
|
|
|
|
|
|
ref_list:
|
2007-06-10 12:43:57 +02:00
|
|
|
ref_list ',' ident { Lex->ref_list.push_back(new Key_part_spec($3.str)); }
|
|
|
|
| ident { Lex->ref_list.push_back(new Key_part_spec($1.str)); };
|
2002-06-02 20:22:20 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_on_delete:
|
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| opt_on_delete_list {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_on_delete_list:
|
|
|
|
opt_on_delete_list opt_on_delete_item {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| opt_on_delete_item {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_on_delete_item:
|
2002-06-02 20:22:20 +02:00
|
|
|
ON DELETE_SYM delete_option { Lex->fk_delete_opt= $3; }
|
|
|
|
| ON UPDATE_SYM delete_option { Lex->fk_update_opt= $3; }
|
2007-06-10 12:43:57 +02:00
|
|
|
| MATCH FULL { Lex->fk_match_option= Foreign_key::FK_MATCH_FULL; }
|
|
|
|
| MATCH PARTIAL { Lex->fk_match_option= Foreign_key::FK_MATCH_PARTIAL; }
|
|
|
|
| MATCH SIMPLE_SYM { Lex->fk_match_option= Foreign_key::FK_MATCH_SIMPLE; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
delete_option:
|
2007-06-10 12:43:57 +02:00
|
|
|
RESTRICT { $$= (int) Foreign_key::FK_OPTION_RESTRICT; }
|
|
|
|
| CASCADE { $$= (int) Foreign_key::FK_OPTION_CASCADE; }
|
|
|
|
| SET NULL_SYM { $$= (int) Foreign_key::FK_OPTION_SET_NULL; }
|
|
|
|
| NO_SYM ACTION { $$= (int) Foreign_key::FK_OPTION_NO_ACTION; }
|
|
|
|
| SET DEFAULT { $$= (int) Foreign_key::FK_OPTION_DEFAULT; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
key_type:
|
2003-12-02 16:06:24 +01:00
|
|
|
key_or_index { $$= Key::MULTIPLE; }
|
2004-01-23 13:02:57 +01:00
|
|
|
| FULLTEXT_SYM opt_key_or_index { $$= Key::FULLTEXT; }
|
|
|
|
| SPATIAL_SYM opt_key_or_index
|
2004-01-15 18:06:22 +01:00
|
|
|
{
|
|
|
|
#ifdef HAVE_SPATIAL
|
|
|
|
$$= Key::SPATIAL;
|
|
|
|
#else
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_FEATURE_DISABLED, MYF(0),
|
|
|
|
sym_group_geom.name, sym_group_geom.needed_define);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-01-15 18:06:22 +01:00
|
|
|
#endif
|
|
|
|
};
|
2003-12-02 16:06:24 +01:00
|
|
|
|
|
|
|
constraint_key_type:
|
|
|
|
PRIMARY_SYM KEY_SYM { $$= Key::PRIMARY; }
|
2004-01-23 13:02:57 +01:00
|
|
|
| UNIQUE_SYM opt_key_or_index { $$= Key::UNIQUE; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
key_or_index:
|
|
|
|
KEY_SYM {}
|
2004-06-23 12:29:05 +02:00
|
|
|
| INDEX_SYM {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2004-01-23 13:02:57 +01:00
|
|
|
opt_key_or_index:
|
|
|
|
/* empty */ {}
|
|
|
|
| key_or_index
|
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
keys_or_index:
|
|
|
|
KEYS {}
|
2004-06-23 12:29:05 +02:00
|
|
|
| INDEX_SYM {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| INDEXES {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2000-08-28 15:43:58 +02:00
|
|
|
opt_unique_or_fulltext:
|
2000-07-31 21:29:14 +02:00
|
|
|
/* empty */ { $$= Key::MULTIPLE; }
|
|
|
|
| UNIQUE_SYM { $$= Key::UNIQUE; }
|
2003-06-16 00:13:23 +02:00
|
|
|
| FULLTEXT_SYM { $$= Key::FULLTEXT;}
|
2004-01-15 18:06:22 +01:00
|
|
|
| SPATIAL_SYM
|
|
|
|
{
|
|
|
|
#ifdef HAVE_SPATIAL
|
|
|
|
$$= Key::SPATIAL;
|
|
|
|
#else
|
2005-02-19 10:51:49 +01:00
|
|
|
my_error(ER_FEATURE_DISABLED, MYF(0),
|
2004-10-20 03:04:37 +02:00
|
|
|
sym_group_geom.name, sym_group_geom.needed_define);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-01-15 18:06:22 +01:00
|
|
|
#endif
|
|
|
|
}
|
2003-06-16 00:13:23 +02:00
|
|
|
;
|
2002-02-22 12:24:42 +01:00
|
|
|
|
2006-05-03 14:59:17 +02:00
|
|
|
init_key_options:
|
|
|
|
{
|
2006-05-03 18:40:52 +02:00
|
|
|
Lex->key_create_info= default_key_create_info;
|
2006-05-03 14:59:17 +02:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
/*
|
2006-05-03 18:40:52 +02:00
|
|
|
For now, key_alg initializies lex->key_create_info.
|
2006-05-03 14:59:17 +02:00
|
|
|
In the future, when all key options are after key definition,
|
|
|
|
we can remove key_alg and move init_key_options to key_options
|
|
|
|
*/
|
|
|
|
|
2002-02-22 12:24:42 +01:00
|
|
|
key_alg:
|
2006-05-03 14:59:17 +02:00
|
|
|
/* empty */ init_key_options
|
2006-05-08 22:06:16 +02:00
|
|
|
| init_key_options key_using_alg
|
2006-05-03 14:59:17 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
key_options:
|
|
|
|
/* empty */ {}
|
|
|
|
| key_opts
|
|
|
|
;
|
|
|
|
|
|
|
|
key_opts:
|
|
|
|
key_opt
|
|
|
|
| key_opts key_opt
|
|
|
|
;
|
2006-05-08 22:06:16 +02:00
|
|
|
|
|
|
|
key_using_alg:
|
|
|
|
USING btree_or_rtree { Lex->key_create_info.algorithm= $2; }
|
|
|
|
| TYPE_SYM btree_or_rtree { Lex->key_create_info.algorithm= $2; }
|
|
|
|
;
|
|
|
|
|
2006-05-03 14:59:17 +02:00
|
|
|
key_opt:
|
2006-05-08 22:06:16 +02:00
|
|
|
key_using_alg
|
2006-05-03 14:59:17 +02:00
|
|
|
| KEY_BLOCK_SIZE opt_equal ulong_num
|
2006-05-03 18:40:52 +02:00
|
|
|
{ Lex->key_create_info.block_size= $3; }
|
2006-05-03 14:59:17 +02:00
|
|
|
| WITH PARSER_SYM IDENT_sys
|
|
|
|
{
|
|
|
|
if (plugin_is_ready(&$3, MYSQL_FTPARSER_PLUGIN))
|
2006-05-03 18:40:52 +02:00
|
|
|
Lex->key_create_info.parser_name= $3;
|
2006-05-03 14:59:17 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
my_error(ER_FUNCTION_NOT_DEFINED, MYF(0), $3.str);
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-05-03 14:59:17 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2002-02-22 12:24:42 +01:00
|
|
|
|
2006-05-08 22:06:16 +02:00
|
|
|
btree_or_rtree:
|
2002-02-22 12:24:42 +01:00
|
|
|
BTREE_SYM { $$= HA_KEY_ALG_BTREE; }
|
2004-01-15 18:06:22 +01:00
|
|
|
| RTREE_SYM
|
|
|
|
{
|
|
|
|
$$= HA_KEY_ALG_RTREE;
|
|
|
|
}
|
2002-06-03 11:59:31 +02:00
|
|
|
| HASH_SYM { $$= HA_KEY_ALG_HASH; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
key_list:
|
|
|
|
key_list ',' key_part order_dir { Lex->col_list.push_back($3); }
|
2002-04-16 01:09:30 +02:00
|
|
|
| key_part order_dir { Lex->col_list.push_back($1); };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
key_part:
|
2007-06-10 12:43:57 +02:00
|
|
|
ident { $$=new Key_part_spec($1.str); }
|
2006-05-08 22:06:16 +02:00
|
|
|
| ident '(' NUM ')'
|
2004-10-26 10:16:35 +02:00
|
|
|
{
|
|
|
|
int key_part_len= atoi($3.str);
|
|
|
|
if (!key_part_len)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_KEY_PART_0, MYF(0), $1.str);
|
2004-10-26 10:16:35 +02:00
|
|
|
}
|
2007-06-10 12:43:57 +02:00
|
|
|
$$=new Key_part_spec($1.str,(uint) key_part_len);
|
2004-10-26 10:16:35 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_ident:
|
|
|
|
/* empty */ { $$=(char*) 0; } /* Defaultlength */
|
2002-04-16 01:09:30 +02:00
|
|
|
| field_ident { $$=$1.str; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-07-06 18:09:57 +02:00
|
|
|
opt_component:
|
2005-01-16 13:16:23 +01:00
|
|
|
/* empty */ { $$= null_lex_str; }
|
|
|
|
| '.' ident { $$= $2; };
|
2003-09-03 11:34:32 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
string_list:
|
|
|
|
text_string { Lex->interval_list.push_back($1); }
|
2002-04-16 01:09:30 +02:00
|
|
|
| string_list ',' text_string { Lex->interval_list.push_back($3); };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
** Alter table
|
|
|
|
*/
|
|
|
|
|
|
|
|
alter:
|
|
|
|
ALTER opt_ignore TABLE_SYM table_ident
|
|
|
|
{
|
2002-11-26 14:18:16 +01:00
|
|
|
THD *thd= YYTHD;
|
2003-12-19 18:52:13 +01:00
|
|
|
LEX *lex= thd->lex;
|
2006-10-16 18:57:33 +02:00
|
|
|
lex->name.str= 0;
|
|
|
|
lex->name.length= 0;
|
2004-12-31 11:04:35 +01:00
|
|
|
lex->sql_command= SQLCOM_ALTER_TABLE;
|
|
|
|
lex->duplicates= DUP_ERROR;
|
2003-01-09 02:55:26 +01:00
|
|
|
if (!lex->select_lex.add_table_to_list(thd, $4, NULL,
|
|
|
|
TL_OPTION_UPDATING))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
lex->alter_info.reset();
|
2000-07-31 21:29:14 +02:00
|
|
|
lex->col_list.empty();
|
2002-11-05 00:10:05 +01:00
|
|
|
lex->select_lex.init_order();
|
A fix and a test case for
Bug#19022 "Memory bug when switching db during trigger execution"
Bug#17199 "Problem when view calls function from another database."
Bug#18444 "Fully qualified stored function names don't work correctly in
SELECT statements"
Documentation note: this patch introduces a change in behaviour of prepared
statements.
This patch adds a few new invariants with regard to how THD::db should
be used. These invariants should be preserved in future:
- one should never refer to THD::db by pointer and always make a deep copy
(strmake, strdup)
- one should never compare two databases by pointer, but use strncmp or
my_strncasecmp
- TABLE_LIST object table->db should be always initialized in the parser or
by creator of the object.
For prepared statements it means that if the current database is changed
after a statement is prepared, the database that was current at prepare
remains active. This also means that you can not prepare a statement that
implicitly refers to the current database if the latter is not set.
This is not documented, and therefore needs documentation. This is NOT a
change in behavior for almost all SQL statements except:
- ALTER TABLE t1 RENAME t2
- OPTIMIZE TABLE t1
- ANALYZE TABLE t1
- TRUNCATE TABLE t1 --
until this patch t1 or t2 could be evaluated at the first execution of
prepared statement.
CURRENT_DATABASE() still works OK and is evaluated at every execution
of prepared statement.
Note, that in stored routines this is not an issue as the default
database is the database of the stored procedure and "use" statement
is prohibited in stored routines.
This patch makes obsolete the use of check_db_used (it was never used in the
old code too) and all other places that check for table->db and assign it
from THD::db if it's NULL, except the parser.
How this patch was created: THD::{db,db_length} were replaced with a
LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
manually checked and:
- if the place uses thd->db by pointer, it was fixed to make a deep copy
- if a place compared two db pointers, it was fixed to compare them by value
(via strcmp/my_strcasecmp, whatever was approproate)
Then this intermediate patch was used to write a smaller patch that does the
same thing but without a rename.
TODO in 5.1:
- remove check_db_used
- deploy THD::set_db in mysql_change_db
See also comments to individual files.
2006-06-26 22:47:52 +02:00
|
|
|
lex->select_lex.db=
|
|
|
|
((TABLE_LIST*) lex->select_lex.table_list.first)->db;
|
2002-11-29 16:17:52 +01:00
|
|
|
bzero((char*) &lex->create_info,sizeof(lex->create_info));
|
2006-05-28 14:51:01 +02:00
|
|
|
lex->create_info.db_type= 0;
|
2004-07-08 12:03:01 +02:00
|
|
|
lex->create_info.default_table_charset= NULL;
|
2001-09-30 04:47:35 +02:00
|
|
|
lex->create_info.row_type= ROW_TYPE_NOT_USED;
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
lex->alter_info.reset();
|
2006-03-29 13:27:36 +02:00
|
|
|
lex->no_write_to_binlog= 0;
|
2006-12-19 23:20:43 +01:00
|
|
|
lex->create_info.storage_media= HA_SM_DEFAULT;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2005-07-18 13:31:02 +02:00
|
|
|
alter_commands
|
2002-11-28 18:57:56 +01:00
|
|
|
{}
|
2004-12-06 17:01:51 +01:00
|
|
|
| ALTER DATABASE ident_or_empty
|
2004-08-27 17:48:19 +02:00
|
|
|
{
|
|
|
|
Lex->create_info.default_table_charset= NULL;
|
|
|
|
Lex->create_info.used_fields= 0;
|
|
|
|
}
|
2007-07-11 23:10:29 +02:00
|
|
|
create_database_options
|
2002-06-27 11:41:02 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command=SQLCOM_ALTER_DB;
|
2004-12-06 17:01:51 +01:00
|
|
|
lex->name= $3;
|
2006-10-16 18:57:33 +02:00
|
|
|
if (lex->name.str == NULL &&
|
2007-07-16 21:31:36 +02:00
|
|
|
lex->copy_db_to(&lex->name.str, &lex->name.length))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
| ALTER PROCEDURE sp_name
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
|
2005-04-20 17:59:28 +02:00
|
|
|
if (lex->sphead)
|
|
|
|
{
|
|
|
|
my_error(ER_SP_NO_DROP_SP, MYF(0), "PROCEDURE");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-04-20 17:59:28 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
bzero((char *)&lex->sp_chistics, sizeof(st_sp_chistics));
|
|
|
|
}
|
|
|
|
sp_a_chistics
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
|
|
|
|
lex->sql_command= SQLCOM_ALTER_PROCEDURE;
|
|
|
|
lex->spname= $3;
|
|
|
|
}
|
|
|
|
| ALTER FUNCTION_SYM sp_name
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2002-06-27 11:41:02 +02:00
|
|
|
|
2005-04-20 17:59:28 +02:00
|
|
|
if (lex->sphead)
|
|
|
|
{
|
|
|
|
my_error(ER_SP_NO_DROP_SP, MYF(0), "FUNCTION");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-04-20 17:59:28 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
bzero((char *)&lex->sp_chistics, sizeof(st_sp_chistics));
|
|
|
|
}
|
|
|
|
sp_a_chistics
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
|
|
|
|
lex->sql_command= SQLCOM_ALTER_FUNCTION;
|
|
|
|
lex->spname= $3;
|
|
|
|
}
|
2007-03-09 13:52:50 +01:00
|
|
|
| ALTER view_algorithm definer
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2007-06-22 15:23:51 +02:00
|
|
|
LEX *lex= Lex;
|
|
|
|
|
|
|
|
if (lex->sphead)
|
2007-06-22 11:55:48 +02:00
|
|
|
{
|
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "ALTER VIEW");
|
|
|
|
MYSQL_YYABORT;
|
|
|
|
}
|
2007-06-22 15:23:51 +02:00
|
|
|
lex->create_view_mode= VIEW_ALTER;
|
2007-03-09 13:52:50 +01:00
|
|
|
}
|
|
|
|
view_tail
|
|
|
|
{}
|
|
|
|
| ALTER definer
|
|
|
|
/*
|
|
|
|
We have two separate rules for ALTER VIEW rather that
|
|
|
|
optional view_algorithm above, to resolve the ambiguity
|
|
|
|
with the ALTER EVENT below.
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2007-06-22 15:38:23 +02:00
|
|
|
|
|
|
|
if (lex->sphead)
|
|
|
|
{
|
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "ALTER VIEW");
|
|
|
|
MYSQL_YYABORT;
|
|
|
|
}
|
2007-03-09 13:52:50 +01:00
|
|
|
lex->create_view_algorithm= VIEW_ALGORITHM_UNDEFINED;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->create_view_mode= VIEW_ALTER;
|
|
|
|
}
|
2007-03-09 13:52:50 +01:00
|
|
|
view_tail
|
2004-11-12 04:01:46 +01:00
|
|
|
{}
|
2007-02-02 18:43:33 +01:00
|
|
|
| ALTER definer EVENT_SYM sp_name
|
2006-02-14 13:19:54 +01:00
|
|
|
/*
|
2006-08-17 14:22:59 +02:00
|
|
|
BE CAREFUL when you add a new rule to update the block where
|
|
|
|
YYTHD->client_capabilities is set back to original value
|
2005-12-07 19:26:44 +01:00
|
|
|
*/
|
2005-12-02 13:07:02 +01:00
|
|
|
{
|
2006-07-13 10:59:58 +02:00
|
|
|
/*
|
2006-08-17 14:22:59 +02:00
|
|
|
It is safe to use Lex->spname because
|
|
|
|
ALTER EVENT xxx RENATE TO yyy DO ALTER EVENT RENAME TO
|
|
|
|
is not allowed. Lex->spname is used in the case of RENAME TO
|
|
|
|
If it had to be supported spname had to be added to
|
|
|
|
Event_parse_data.
|
2006-07-13 10:59:58 +02:00
|
|
|
*/
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2006-06-27 10:53:26 +02:00
|
|
|
if (!(Lex->event_parse_data= Event_parse_data::new_instance(YYTHD)))
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2007-02-02 18:43:33 +01:00
|
|
|
Lex->event_parse_data->identifier= $4;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2005-12-02 13:07:02 +01:00
|
|
|
/*
|
2006-08-17 14:22:59 +02:00
|
|
|
We have to turn off CLIENT_MULTI_QUERIES while parsing a
|
2006-06-27 10:53:26 +02:00
|
|
|
stored procedure, otherwise yylex will chop it into pieces
|
|
|
|
at each ';'.
|
2005-12-02 13:07:02 +01:00
|
|
|
*/
|
2005-12-05 11:45:04 +01:00
|
|
|
$<ulong_num>$= YYTHD->client_capabilities & CLIENT_MULTI_QUERIES;
|
2005-12-02 13:07:02 +01:00
|
|
|
YYTHD->client_capabilities &= ~CLIENT_MULTI_QUERIES;
|
2006-06-29 11:53:51 +02:00
|
|
|
|
|
|
|
Lex->sql_command= SQLCOM_ALTER_EVENT;
|
2005-12-02 13:07:02 +01:00
|
|
|
}
|
2006-01-20 16:12:44 +01:00
|
|
|
ev_alter_on_schedule_completion
|
|
|
|
opt_ev_rename_to
|
|
|
|
opt_ev_status
|
|
|
|
opt_ev_comment
|
|
|
|
opt_ev_sql_stmt
|
2005-12-02 13:07:02 +01:00
|
|
|
{
|
2005-12-07 19:26:44 +01:00
|
|
|
/*
|
|
|
|
$1 - ALTER
|
2007-02-02 18:43:33 +01:00
|
|
|
$2 - definer
|
|
|
|
$3 - EVENT_SYM
|
|
|
|
$4 - sp_name
|
|
|
|
$5 - the block above
|
2005-12-07 19:26:44 +01:00
|
|
|
*/
|
2007-02-02 18:43:33 +01:00
|
|
|
YYTHD->client_capabilities |= $<ulong_num>5;
|
2005-12-07 19:26:44 +01:00
|
|
|
|
2007-02-02 18:43:33 +01:00
|
|
|
if (!($6 || $7 || $8 || $9 || $10))
|
2005-12-28 12:43:27 +01:00
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-12-28 12:43:27 +01:00
|
|
|
}
|
2006-06-29 11:53:51 +02:00
|
|
|
/*
|
|
|
|
sql_command is set here because some rules in ev_sql_stmt
|
|
|
|
can overwrite it
|
|
|
|
*/
|
2005-12-05 11:45:04 +01:00
|
|
|
Lex->sql_command= SQLCOM_ALTER_EVENT;
|
2006-01-11 12:01:36 +01:00
|
|
|
}
|
2006-01-11 11:35:25 +01:00
|
|
|
| ALTER TABLESPACE alter_tablespace_info
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->ts_cmd_type= ALTER_TABLESPACE;
|
|
|
|
}
|
2007-02-23 21:48:15 +01:00
|
|
|
| ALTER LOGFILE_SYM GROUP_SYM alter_logfile_group_info
|
2006-01-11 11:35:25 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->ts_cmd_type= ALTER_LOGFILE_GROUP;
|
|
|
|
}
|
|
|
|
| ALTER TABLESPACE change_tablespace_info
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->ts_cmd_type= CHANGE_FILE_TABLESPACE;
|
|
|
|
}
|
2006-02-14 13:19:54 +01:00
|
|
|
| ALTER TABLESPACE change_tablespace_access
|
2006-01-11 11:35:25 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->ts_cmd_type= ALTER_ACCESS_MODE_TABLESPACE;
|
|
|
|
}
|
2006-12-02 01:47:45 +01:00
|
|
|
| ALTER SERVER_SYM ident_or_text OPTIONS_SYM '(' server_options_list ')'
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2007-01-29 00:47:35 +01:00
|
|
|
lex->sql_command= SQLCOM_ALTER_SERVER;
|
|
|
|
lex->server_options.server_name= $3.str;
|
|
|
|
lex->server_options.server_name_length= $3.length;
|
2006-12-02 01:47:45 +01:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
2005-12-02 13:07:02 +01:00
|
|
|
|
2006-02-14 13:19:54 +01:00
|
|
|
ev_alter_on_schedule_completion: /* empty */ { $$= 0;}
|
|
|
|
| ON SCHEDULE_SYM ev_schedule_time { $$= 1; }
|
|
|
|
| ev_on_completion { $$= 1; }
|
|
|
|
| ON SCHEDULE_SYM ev_schedule_time ev_on_completion { $$= 1; }
|
2006-01-20 16:12:44 +01:00
|
|
|
;
|
2006-01-11 12:49:56 +01:00
|
|
|
|
2006-02-14 13:19:54 +01:00
|
|
|
opt_ev_rename_to: /* empty */ { $$= 0;}
|
2005-12-02 13:07:02 +01:00
|
|
|
| RENAME TO_SYM sp_name
|
|
|
|
{
|
2006-08-17 14:22:59 +02:00
|
|
|
/*
|
|
|
|
Use lex's spname to hold the new name.
|
|
|
|
The original name is in the Event_parse_data object
|
|
|
|
*/
|
|
|
|
Lex->spname= $3;
|
2006-02-14 13:19:54 +01:00
|
|
|
$$= 1;
|
2005-12-02 13:07:02 +01:00
|
|
|
}
|
|
|
|
;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
|
|
|
opt_ev_sql_stmt: /* empty*/ { $$= 0;}
|
|
|
|
| DO_SYM ev_sql_stmt { $$= 1; }
|
2006-01-11 12:49:56 +01:00
|
|
|
;
|
2005-12-28 12:43:27 +01:00
|
|
|
|
2004-12-06 17:01:51 +01:00
|
|
|
ident_or_empty:
|
2006-10-16 18:57:33 +02:00
|
|
|
/* empty */ { $$.str= 0; $$.length= 0; }
|
|
|
|
| ident { $$= $1; };
|
2004-12-06 17:01:51 +01:00
|
|
|
|
2005-07-18 13:31:02 +02:00
|
|
|
alter_commands:
|
2004-05-21 16:57:03 +02:00
|
|
|
| DISCARD TABLESPACE { Lex->alter_info.tablespace_op= DISCARD_TABLESPACE; }
|
|
|
|
| IMPORT TABLESPACE { Lex->alter_info.tablespace_op= IMPORT_TABLESPACE; }
|
2005-07-18 13:31:02 +02:00
|
|
|
| alter_list
|
2006-01-17 08:40:00 +01:00
|
|
|
opt_partitioning
|
2006-03-20 20:36:21 +01:00
|
|
|
| alter_list
|
|
|
|
remove_partitioning
|
|
|
|
| remove_partitioning
|
2005-07-18 13:31:02 +02:00
|
|
|
| partitioning
|
2005-08-19 16:26:05 +02:00
|
|
|
/*
|
2006-12-07 13:57:39 +01:00
|
|
|
This part was added for release 5.1 by Mikael Ronström.
|
2005-08-19 16:26:05 +02:00
|
|
|
From here we insert a number of commands to manage the partitions of a
|
|
|
|
partitioned table such as adding partitions, dropping partitions,
|
|
|
|
reorganising partitions in various manners. In future releases the list
|
|
|
|
will be longer and also include moving partitions to a
|
|
|
|
new table and so forth.
|
|
|
|
*/
|
|
|
|
| add_partition_rule
|
|
|
|
| DROP PARTITION_SYM alt_part_name_list
|
|
|
|
{
|
|
|
|
Lex->alter_info.flags|= ALTER_DROP_PARTITION;
|
|
|
|
}
|
2006-01-17 08:40:00 +01:00
|
|
|
| REBUILD_SYM PARTITION_SYM opt_no_write_to_binlog
|
|
|
|
all_or_alt_part_name_list
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_info.flags|= ALTER_REBUILD_PARTITION;
|
|
|
|
lex->no_write_to_binlog= $3;
|
|
|
|
}
|
|
|
|
| OPTIMIZE PARTITION_SYM opt_no_write_to_binlog
|
|
|
|
all_or_alt_part_name_list
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_info.flags|= ALTER_OPTIMIZE_PARTITION;
|
|
|
|
lex->no_write_to_binlog= $3;
|
|
|
|
lex->check_opt.init();
|
|
|
|
}
|
|
|
|
opt_no_write_to_binlog opt_mi_check_type
|
|
|
|
| ANALYZE_SYM PARTITION_SYM opt_no_write_to_binlog
|
|
|
|
all_or_alt_part_name_list
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_info.flags|= ALTER_ANALYZE_PARTITION;
|
|
|
|
lex->no_write_to_binlog= $3;
|
|
|
|
lex->check_opt.init();
|
|
|
|
}
|
|
|
|
opt_mi_check_type
|
|
|
|
| CHECK_SYM PARTITION_SYM all_or_alt_part_name_list
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_info.flags|= ALTER_CHECK_PARTITION;
|
|
|
|
lex->check_opt.init();
|
|
|
|
}
|
|
|
|
opt_mi_check_type
|
|
|
|
| REPAIR PARTITION_SYM opt_no_write_to_binlog
|
|
|
|
all_or_alt_part_name_list
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_info.flags|= ALTER_REPAIR_PARTITION;
|
|
|
|
lex->no_write_to_binlog= $3;
|
|
|
|
lex->check_opt.init();
|
|
|
|
}
|
|
|
|
opt_mi_repair_type
|
2006-08-07 18:02:28 +02:00
|
|
|
| COALESCE PARTITION_SYM opt_no_write_to_binlog real_ulong_num
|
2005-08-19 16:26:05 +02:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_info.flags|= ALTER_COALESCE_PARTITION;
|
2006-01-17 08:40:00 +01:00
|
|
|
lex->no_write_to_binlog= $3;
|
|
|
|
lex->alter_info.no_parts= $4;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
| reorg_partition_rule
|
2005-07-18 13:31:02 +02:00
|
|
|
;
|
|
|
|
|
2006-03-20 20:36:21 +01:00
|
|
|
remove_partitioning:
|
|
|
|
REMOVE_SYM PARTITIONING_SYM
|
|
|
|
{
|
|
|
|
Lex->alter_info.flags|= ALTER_REMOVE_PARTITIONING;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2006-01-17 08:40:00 +01:00
|
|
|
all_or_alt_part_name_list:
|
2006-03-09 19:19:25 +01:00
|
|
|
ALL
|
2006-01-17 08:40:00 +01:00
|
|
|
{
|
|
|
|
Lex->alter_info.flags|= ALTER_ALL_PARTITION;
|
|
|
|
}
|
|
|
|
| alt_part_name_list
|
|
|
|
;
|
|
|
|
|
2005-08-19 16:26:05 +02:00
|
|
|
add_partition_rule:
|
2006-01-17 08:40:00 +01:00
|
|
|
ADD PARTITION_SYM opt_no_write_to_binlog
|
2005-08-19 16:26:05 +02:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->part_info= new partition_info();
|
|
|
|
if (!lex->part_info)
|
|
|
|
{
|
2006-01-17 08:40:00 +01:00
|
|
|
mem_alloc_error(sizeof(partition_info));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
lex->alter_info.flags|= ALTER_ADD_PARTITION;
|
2006-01-17 08:40:00 +01:00
|
|
|
lex->no_write_to_binlog= $3;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
add_part_extra
|
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
|
|
|
add_part_extra:
|
|
|
|
| '(' part_def_list ')'
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-01-17 08:40:00 +01:00
|
|
|
lex->part_info->no_parts= lex->part_info->partitions.elements;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
2006-08-07 18:02:28 +02:00
|
|
|
| PARTITIONS_SYM real_ulong_num
|
2005-08-19 16:26:05 +02:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->part_info->no_parts= $2;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
reorg_partition_rule:
|
2006-01-17 08:40:00 +01:00
|
|
|
REORGANIZE_SYM PARTITION_SYM opt_no_write_to_binlog
|
2005-08-19 16:26:05 +02:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->part_info= new partition_info();
|
|
|
|
if (!lex->part_info)
|
|
|
|
{
|
2006-01-17 08:40:00 +01:00
|
|
|
mem_alloc_error(sizeof(partition_info));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
2006-01-17 08:40:00 +01:00
|
|
|
lex->no_write_to_binlog= $3;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
2006-01-17 08:40:00 +01:00
|
|
|
reorg_parts_rule
|
|
|
|
;
|
|
|
|
|
|
|
|
reorg_parts_rule:
|
|
|
|
/* empty */
|
|
|
|
{
|
|
|
|
Lex->alter_info.flags|= ALTER_TABLE_REORG;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
alt_part_name_list
|
|
|
|
{
|
|
|
|
Lex->alter_info.flags|= ALTER_REORGANIZE_PARTITION;
|
|
|
|
}
|
|
|
|
INTO '(' part_def_list ')'
|
2005-08-19 16:26:05 +02:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-01-17 08:40:00 +01:00
|
|
|
lex->part_info->no_parts= lex->part_info->partitions.elements;
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
alt_part_name_list:
|
|
|
|
alt_part_name_item {}
|
|
|
|
| alt_part_name_list ',' alt_part_name_item {}
|
|
|
|
;
|
|
|
|
|
|
|
|
alt_part_name_item:
|
|
|
|
ident
|
|
|
|
{
|
2006-01-17 08:40:00 +01:00
|
|
|
if (Lex->alter_info.partition_names.push_back($1.str))
|
|
|
|
{
|
|
|
|
mem_alloc_error(1);
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-17 08:40:00 +01:00
|
|
|
}
|
2005-08-19 16:26:05 +02:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
/*
|
|
|
|
End of management of partition commands
|
|
|
|
*/
|
|
|
|
|
2005-07-18 13:31:02 +02:00
|
|
|
alter_list:
|
|
|
|
alter_list_item
|
|
|
|
| alter_list ',' alter_list_item
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
add_column:
|
2004-11-12 04:01:46 +01:00
|
|
|
ADD opt_column
|
2004-03-30 19:22:14 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->change=0;
|
|
|
|
lex->alter_info.flags|= ALTER_ADD_COLUMN;
|
2004-03-30 19:22:14 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
alter_list_item:
|
2004-11-12 04:01:46 +01:00
|
|
|
add_column column_def opt_place { }
|
|
|
|
| ADD key_def
|
|
|
|
{
|
|
|
|
Lex->alter_info.flags|= ALTER_ADD_INDEX;
|
2004-03-30 19:22:14 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
| add_column '(' field_list ')'
|
|
|
|
{
|
|
|
|
Lex->alter_info.flags|= ALTER_ADD_COLUMN | ALTER_ADD_INDEX;
|
|
|
|
}
|
2001-06-15 04:03:15 +02:00
|
|
|
| CHANGE opt_column field_ident
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->change= $3.str;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.flags|= ALTER_CHANGE_COLUMN;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2001-10-29 09:49:35 +01:00
|
|
|
field_spec opt_place
|
2002-06-04 07:23:57 +02:00
|
|
|
| MODIFY_SYM opt_column field_ident
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2004-12-02 09:48:43 +01:00
|
|
|
lex->length=lex->dec=0; lex->type=0;
|
2004-04-02 08:12:53 +02:00
|
|
|
lex->default_value= lex->on_update_value= 0;
|
2005-01-16 13:16:23 +01:00
|
|
|
lex->comment=null_lex_str;
|
2003-06-30 12:23:54 +02:00
|
|
|
lex->charset= NULL;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.flags|= ALTER_CHANGE_COLUMN;
|
2002-06-04 07:23:57 +02:00
|
|
|
}
|
|
|
|
type opt_attribute
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2007-04-03 13:13:27 +02:00
|
|
|
if (add_field_to_list(lex->thd,&$3,
|
2002-06-04 07:23:57 +02:00
|
|
|
(enum enum_field_types) $5,
|
|
|
|
lex->length,lex->dec,lex->type,
|
2004-04-02 08:12:53 +02:00
|
|
|
lex->default_value, lex->on_update_value,
|
2005-01-16 13:16:23 +01:00
|
|
|
&lex->comment,
|
2004-12-02 09:48:43 +01:00
|
|
|
$3.str, &lex->interval_list, lex->charset,
|
2003-03-27 10:09:09 +01:00
|
|
|
lex->uint_geom_type))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-06-04 07:23:57 +02:00
|
|
|
}
|
|
|
|
opt_place
|
2000-07-31 21:29:14 +02:00
|
|
|
| DROP opt_column field_ident opt_restrict
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.drop_list.push_back(new Alter_drop(Alter_drop::COLUMN,
|
2004-11-12 04:01:46 +01:00
|
|
|
$3.str));
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.flags|= ALTER_DROP_COLUMN;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
| DROP FOREIGN KEY_SYM opt_ident
|
|
|
|
{
|
2006-03-30 20:55:54 +02:00
|
|
|
Lex->alter_info.flags|= ALTER_DROP_INDEX | ALTER_FOREIGN_KEY;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2001-06-15 04:03:15 +02:00
|
|
|
| DROP PRIMARY_SYM KEY_SYM
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.drop_list.push_back(new Alter_drop(Alter_drop::KEY,
|
|
|
|
primary_key_name));
|
|
|
|
lex->alter_info.flags|= ALTER_DROP_INDEX;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| DROP key_or_index field_ident
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.drop_list.push_back(new Alter_drop(Alter_drop::KEY,
|
|
|
|
$3.str));
|
|
|
|
lex->alter_info.flags|= ALTER_DROP_INDEX;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
| DISABLE_SYM KEYS
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->alter_info.keys_onoff= DISABLE;
|
|
|
|
lex->alter_info.flags|= ALTER_KEYS_ONOFF;
|
|
|
|
}
|
|
|
|
| ENABLE_SYM KEYS
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->alter_info.keys_onoff= ENABLE;
|
|
|
|
lex->alter_info.flags|= ALTER_KEYS_ONOFF;
|
|
|
|
}
|
2003-12-11 17:05:51 +01:00
|
|
|
| ALTER opt_column field_ident SET DEFAULT signed_literal
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.alter_list.push_back(new Alter_column($3.str,$6));
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->alter_info.flags|= ALTER_CHANGE_COLUMN_DEFAULT;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| ALTER opt_column field_ident DROP DEFAULT
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.alter_list.push_back(new Alter_column($3.str,
|
|
|
|
(Item*) 0));
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->alter_info.flags|= ALTER_CHANGE_COLUMN_DEFAULT;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2002-04-29 11:24:14 +02:00
|
|
|
| RENAME opt_to table_ident
|
2002-12-02 20:38:00 +01:00
|
|
|
{
|
2001-06-07 13:10:58 +02:00
|
|
|
LEX *lex=Lex;
|
WL#3817: Simplify string / memory area types and make things more consistent (first part)
The following type conversions was done:
- Changed byte to uchar
- Changed gptr to uchar*
- Change my_string to char *
- Change my_size_t to size_t
- Change size_s to size_t
Removed declaration of byte, gptr, my_string, my_size_t and size_s.
Following function parameter changes was done:
- All string functions in mysys/strings was changed to use size_t
instead of uint for string lengths.
- All read()/write() functions changed to use size_t (including vio).
- All protocoll functions changed to use size_t instead of uint
- Functions that used a pointer to a string length was changed to use size_t*
- Changed malloc(), free() and related functions from using gptr to use void *
as this requires fewer casts in the code and is more in line with how the
standard functions work.
- Added extra length argument to dirname_part() to return the length of the
created string.
- Changed (at least) following functions to take uchar* as argument:
- db_dump()
- my_net_write()
- net_write_command()
- net_store_data()
- DBUG_DUMP()
- decimal2bin() & bin2decimal()
- Changed my_compress() and my_uncompress() to use size_t. Changed one
argument to my_uncompress() from a pointer to a value as we only return
one value (makes function easier to use).
- Changed type of 'pack_data' argument to packfrm() to avoid casts.
- Changed in readfrm() and writefrom(), ha_discover and handler::discover()
the type for argument 'frmdata' to uchar** to avoid casts.
- Changed most Field functions to use uchar* instead of char* (reduced a lot of
casts).
- Changed field->val_xxx(xxx, new_ptr) to take const pointers.
Other changes:
- Removed a lot of not needed casts
- Added a few new cast required by other changes
- Added some cast to my_multi_malloc() arguments for safety (as string lengths
needs to be uint, not size_t).
- Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
explicitely as this conflict was often hided by casting the function to
hash_get_key).
- Changed some buffers to memory regions to uchar* to avoid casts.
- Changed some string lengths from uint to size_t.
- Changed field->ptr to be uchar* instead of char*. This allowed us to
get rid of a lot of casts.
- Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
- Include zlib.h in some files as we needed declaration of crc32()
- Changed MY_FILE_ERROR to be (size_t) -1.
- Changed many variables to hold the result of my_read() / my_write() to be
size_t. This was needed to properly detect errors (which are
returned as (size_t) -1).
- Removed some very old VMS code
- Changed packfrm()/unpackfrm() to not be depending on uint size
(portability fix)
- Removed windows specific code to restore cursor position as this
causes slowdown on windows and we should not mix read() and pread()
calls anyway as this is not thread safe. Updated function comment to
reflect this. Changed function that depended on original behavior of
my_pwrite() to itself restore the cursor position (one such case).
- Added some missing checking of return value of malloc().
- Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
- Changed type of table_def::m_size from my_size_t to ulong to reflect that
m_size is the number of elements in the array, not a string/memory
length.
- Moved THD::max_row_length() to table.cc (as it's not depending on THD).
Inlined max_row_length_blob() into this function.
- More function comments
- Fixed some compiler warnings when compiled without partitions.
- Removed setting of LEX_STRING() arguments in declaration (portability fix).
- Some trivial indentation/variable name changes.
- Some trivial code simplifications:
- Replaced some calls to alloc_root + memcpy to use
strmake_root()/strdup_root().
- Changed some calls from memdup() to strmake() (Safety fix)
- Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
|
|
|
size_t dummy;
|
2002-10-30 12:18:52 +01:00
|
|
|
lex->select_lex.db=$3->db.str;
|
A fix and a test case for
Bug#19022 "Memory bug when switching db during trigger execution"
Bug#17199 "Problem when view calls function from another database."
Bug#18444 "Fully qualified stored function names don't work correctly in
SELECT statements"
Documentation note: this patch introduces a change in behaviour of prepared
statements.
This patch adds a few new invariants with regard to how THD::db should
be used. These invariants should be preserved in future:
- one should never refer to THD::db by pointer and always make a deep copy
(strmake, strdup)
- one should never compare two databases by pointer, but use strncmp or
my_strncasecmp
- TABLE_LIST object table->db should be always initialized in the parser or
by creator of the object.
For prepared statements it means that if the current database is changed
after a statement is prepared, the database that was current at prepare
remains active. This also means that you can not prepare a statement that
implicitly refers to the current database if the latter is not set.
This is not documented, and therefore needs documentation. This is NOT a
change in behavior for almost all SQL statements except:
- ALTER TABLE t1 RENAME t2
- OPTIMIZE TABLE t1
- ANALYZE TABLE t1
- TRUNCATE TABLE t1 --
until this patch t1 or t2 could be evaluated at the first execution of
prepared statement.
CURRENT_DATABASE() still works OK and is evaluated at every execution
of prepared statement.
Note, that in stored routines this is not an issue as the default
database is the database of the stored procedure and "use" statement
is prohibited in stored routines.
This patch makes obsolete the use of check_db_used (it was never used in the
old code too) and all other places that check for table->db and assign it
from THD::db if it's NULL, except the parser.
How this patch was created: THD::{db,db_length} were replaced with a
LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
manually checked and:
- if the place uses thd->db by pointer, it was fixed to make a deep copy
- if a place compared two db pointers, it was fixed to compare them by value
(via strcmp/my_strcasecmp, whatever was approproate)
Then this intermediate patch was used to write a smaller patch that does the
same thing but without a rename.
TODO in 5.1:
- remove check_db_used
- deploy THD::set_db in mysql_change_db
See also comments to individual files.
2006-06-26 22:47:52 +02:00
|
|
|
if (lex->select_lex.db == NULL &&
|
2007-07-16 21:31:36 +02:00
|
|
|
lex->copy_db_to(&lex->select_lex.db, &dummy))
|
A fix and a test case for
Bug#19022 "Memory bug when switching db during trigger execution"
Bug#17199 "Problem when view calls function from another database."
Bug#18444 "Fully qualified stored function names don't work correctly in
SELECT statements"
Documentation note: this patch introduces a change in behaviour of prepared
statements.
This patch adds a few new invariants with regard to how THD::db should
be used. These invariants should be preserved in future:
- one should never refer to THD::db by pointer and always make a deep copy
(strmake, strdup)
- one should never compare two databases by pointer, but use strncmp or
my_strncasecmp
- TABLE_LIST object table->db should be always initialized in the parser or
by creator of the object.
For prepared statements it means that if the current database is changed
after a statement is prepared, the database that was current at prepare
remains active. This also means that you can not prepare a statement that
implicitly refers to the current database if the latter is not set.
This is not documented, and therefore needs documentation. This is NOT a
change in behavior for almost all SQL statements except:
- ALTER TABLE t1 RENAME t2
- OPTIMIZE TABLE t1
- ANALYZE TABLE t1
- TRUNCATE TABLE t1 --
until this patch t1 or t2 could be evaluated at the first execution of
prepared statement.
CURRENT_DATABASE() still works OK and is evaluated at every execution
of prepared statement.
Note, that in stored routines this is not an issue as the default
database is the database of the stored procedure and "use" statement
is prohibited in stored routines.
This patch makes obsolete the use of check_db_used (it was never used in the
old code too) and all other places that check for table->db and assign it
from THD::db if it's NULL, except the parser.
How this patch was created: THD::{db,db_length} were replaced with a
LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
manually checked and:
- if the place uses thd->db by pointer, it was fixed to make a deep copy
- if a place compared two db pointers, it was fixed to compare them by value
(via strcmp/my_strcasecmp, whatever was approproate)
Then this intermediate patch was used to write a smaller patch that does the
same thing but without a rename.
TODO in 5.1:
- remove check_db_used
- deploy THD::set_db in mysql_change_db
See also comments to individual files.
2006-06-26 22:47:52 +02:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
A fix and a test case for
Bug#19022 "Memory bug when switching db during trigger execution"
Bug#17199 "Problem when view calls function from another database."
Bug#18444 "Fully qualified stored function names don't work correctly in
SELECT statements"
Documentation note: this patch introduces a change in behaviour of prepared
statements.
This patch adds a few new invariants with regard to how THD::db should
be used. These invariants should be preserved in future:
- one should never refer to THD::db by pointer and always make a deep copy
(strmake, strdup)
- one should never compare two databases by pointer, but use strncmp or
my_strncasecmp
- TABLE_LIST object table->db should be always initialized in the parser or
by creator of the object.
For prepared statements it means that if the current database is changed
after a statement is prepared, the database that was current at prepare
remains active. This also means that you can not prepare a statement that
implicitly refers to the current database if the latter is not set.
This is not documented, and therefore needs documentation. This is NOT a
change in behavior for almost all SQL statements except:
- ALTER TABLE t1 RENAME t2
- OPTIMIZE TABLE t1
- ANALYZE TABLE t1
- TRUNCATE TABLE t1 --
until this patch t1 or t2 could be evaluated at the first execution of
prepared statement.
CURRENT_DATABASE() still works OK and is evaluated at every execution
of prepared statement.
Note, that in stored routines this is not an issue as the default
database is the database of the stored procedure and "use" statement
is prohibited in stored routines.
This patch makes obsolete the use of check_db_used (it was never used in the
old code too) and all other places that check for table->db and assign it
from THD::db if it's NULL, except the parser.
How this patch was created: THD::{db,db_length} were replaced with a
LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
manually checked and:
- if the place uses thd->db by pointer, it was fixed to make a deep copy
- if a place compared two db pointers, it was fixed to compare them by value
(via strcmp/my_strcasecmp, whatever was approproate)
Then this intermediate patch was used to write a smaller patch that does the
same thing but without a rename.
TODO in 5.1:
- remove check_db_used
- deploy THD::set_db in mysql_change_db
See also comments to individual files.
2006-06-26 22:47:52 +02:00
|
|
|
}
|
2004-07-26 10:52:40 +02:00
|
|
|
if (check_table_name($3->table.str,$3->table.length) ||
|
2006-10-16 18:57:33 +02:00
|
|
|
$3->db.str && check_db_name(&$3->db))
|
2004-07-26 10:52:40 +02:00
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_WRONG_TABLE_NAME, MYF(0), $3->table.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-07-26 10:52:40 +02:00
|
|
|
}
|
2006-10-16 18:57:33 +02:00
|
|
|
lex->name= $3->table;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.flags|= ALTER_RENAME;
|
2001-06-07 13:10:58 +02:00
|
|
|
}
|
2004-03-30 18:33:45 +02:00
|
|
|
| CONVERT_SYM TO_SYM charset charset_name_or_default opt_collate
|
|
|
|
{
|
|
|
|
if (!$4)
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
$4= thd->variables.collation_database;
|
|
|
|
}
|
|
|
|
$5= $5 ? $5 : $4;
|
|
|
|
if (!my_charset_same($4,$5))
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_COLLATION_CHARSET_MISMATCH, MYF(0),
|
|
|
|
$5->name, $4->csname);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-03-30 18:33:45 +02:00
|
|
|
}
|
2004-03-30 19:18:49 +02:00
|
|
|
LEX *lex= Lex;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->create_info.table_charset=
|
2004-03-31 02:32:38 +02:00
|
|
|
lex->create_info.default_table_charset= $5;
|
|
|
|
lex->create_info.used_fields|= (HA_CREATE_USED_CHARSET |
|
|
|
|
HA_CREATE_USED_DEFAULT_CHARSET);
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->alter_info.flags|= ALTER_CONVERT;
|
2004-03-30 18:33:45 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
| create_table_options_space_separated
|
2004-03-30 19:22:14 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.flags|= ALTER_OPTIONS;
|
2004-03-30 19:22:14 +02:00
|
|
|
}
|
2005-05-25 17:33:36 +02:00
|
|
|
| FORCE_SYM
|
|
|
|
{
|
|
|
|
Lex->alter_info.flags|= ALTER_FORCE;
|
|
|
|
}
|
2007-01-19 02:37:52 +01:00
|
|
|
| alter_order_clause
|
2004-03-30 19:22:14 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.flags|= ALTER_ORDER;
|
2004-03-30 19:22:14 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_column:
|
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| COLUMN_SYM {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_ignore:
|
2004-12-31 11:04:35 +01:00
|
|
|
/* empty */ { Lex->ignore= 0;}
|
|
|
|
| IGNORE_SYM { Lex->ignore= 1;}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_restrict:
|
2004-11-12 04:01:46 +01:00
|
|
|
/* empty */ { Lex->drop_mode= DROP_DEFAULT; }
|
|
|
|
| RESTRICT { Lex->drop_mode= DROP_RESTRICT; }
|
|
|
|
| CASCADE { Lex->drop_mode= DROP_CASCADE; }
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_place:
|
|
|
|
/* empty */ {}
|
|
|
|
| AFTER_SYM ident { store_position_for_column($2.str); }
|
2002-04-16 01:09:30 +02:00
|
|
|
| FIRST_SYM { store_position_for_column(first_keyword); };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_to:
|
|
|
|
/* empty */ {}
|
|
|
|
| TO_SYM {}
|
2002-04-29 11:24:14 +02:00
|
|
|
| EQ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| AS {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-10-24 11:52:51 +02:00
|
|
|
/*
|
2003-09-15 12:43:31 +02:00
|
|
|
SLAVE START and SLAVE STOP are deprecated. We keep them for compatibility.
|
2002-11-21 14:56:48 +01:00
|
|
|
*/
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
slave:
|
2004-11-12 04:01:46 +01:00
|
|
|
START_SYM SLAVE slave_thread_opts
|
2003-09-13 22:13:41 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command = SQLCOM_SLAVE_START;
|
|
|
|
lex->type = 0;
|
|
|
|
/* We'll use mi structure for UNTIL options */
|
|
|
|
bzero((char*) &lex->mi, sizeof(lex->mi));
|
2004-01-26 20:16:37 +01:00
|
|
|
/* If you change this code don't forget to update SLAVE START too */
|
2003-09-13 22:13:41 +02:00
|
|
|
}
|
|
|
|
slave_until
|
|
|
|
{}
|
2002-11-21 14:56:48 +01:00
|
|
|
| STOP_SYM SLAVE slave_thread_opts
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command = SQLCOM_SLAVE_STOP;
|
|
|
|
lex->type = 0;
|
2004-01-26 20:16:37 +01:00
|
|
|
/* If you change this code don't forget to update SLAVE STOP too */
|
2002-11-21 14:56:48 +01:00
|
|
|
}
|
2003-09-15 12:43:31 +02:00
|
|
|
| SLAVE START_SYM slave_thread_opts
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command = SQLCOM_SLAVE_START;
|
|
|
|
lex->type = 0;
|
2004-01-26 19:39:00 +01:00
|
|
|
/* We'll use mi structure for UNTIL options */
|
|
|
|
bzero((char*) &lex->mi, sizeof(lex->mi));
|
|
|
|
}
|
|
|
|
slave_until
|
|
|
|
{}
|
2003-09-15 12:43:31 +02:00
|
|
|
| SLAVE STOP_SYM slave_thread_opts
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command = SQLCOM_SLAVE_STOP;
|
|
|
|
lex->type = 0;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2000-08-21 23:39:08 +02:00
|
|
|
|
2003-02-06 15:55:59 +01:00
|
|
|
start:
|
2004-11-10 17:56:45 +01:00
|
|
|
START_SYM TRANSACTION_SYM start_transaction_opts
|
|
|
|
{
|
2005-06-07 12:53:08 +02:00
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command= SQLCOM_BEGIN;
|
|
|
|
lex->start_transaction_opt= $3;
|
2004-11-10 17:56:45 +01:00
|
|
|
}
|
2003-02-06 15:55:59 +01:00
|
|
|
;
|
|
|
|
|
2004-11-10 17:56:45 +01:00
|
|
|
start_transaction_opts:
|
|
|
|
/*empty*/ { $$ = 0; }
|
|
|
|
| WITH CONSISTENT_SYM SNAPSHOT_SYM
|
|
|
|
{
|
|
|
|
$$= MYSQL_START_TRANS_OPT_WITH_CONS_SNAPSHOT;
|
|
|
|
}
|
2004-11-11 07:50:46 +01:00
|
|
|
;
|
2004-11-10 17:56:45 +01:00
|
|
|
|
2002-07-23 17:31:22 +02:00
|
|
|
slave_thread_opts:
|
2003-02-12 20:55:37 +01:00
|
|
|
{ Lex->slave_thd_opt= 0; }
|
|
|
|
slave_thread_opt_list
|
2003-09-13 22:13:41 +02:00
|
|
|
{}
|
2003-02-13 07:14:35 +01:00
|
|
|
;
|
2003-02-12 20:55:37 +01:00
|
|
|
|
|
|
|
slave_thread_opt_list:
|
2002-07-23 17:31:22 +02:00
|
|
|
slave_thread_opt
|
2003-02-12 20:55:37 +01:00
|
|
|
| slave_thread_opt_list ',' slave_thread_opt
|
|
|
|
;
|
2002-03-10 05:48:06 +01:00
|
|
|
|
|
|
|
slave_thread_opt:
|
2002-12-04 23:14:51 +01:00
|
|
|
/*empty*/ {}
|
2002-07-23 17:31:22 +02:00
|
|
|
| SQL_THREAD { Lex->slave_thd_opt|=SLAVE_SQL; }
|
2003-04-16 08:25:43 +02:00
|
|
|
| RELAY_THREAD { Lex->slave_thd_opt|=SLAVE_IO; }
|
2002-07-23 17:31:22 +02:00
|
|
|
;
|
2002-12-04 23:14:51 +01:00
|
|
|
|
2003-09-13 22:13:41 +02:00
|
|
|
slave_until:
|
|
|
|
/*empty*/ {}
|
|
|
|
| UNTIL_SYM slave_until_opts
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
if ((lex->mi.log_file_name || lex->mi.pos) &&
|
|
|
|
(lex->mi.relay_log_name || lex->mi.relay_log_pos) ||
|
|
|
|
!((lex->mi.log_file_name && lex->mi.pos) ||
|
|
|
|
(lex->mi.relay_log_name && lex->mi.relay_log_pos)))
|
|
|
|
{
|
2004-11-12 13:34:00 +01:00
|
|
|
my_message(ER_BAD_SLAVE_UNTIL_COND,
|
|
|
|
ER(ER_BAD_SLAVE_UNTIL_COND), MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-09-13 22:13:41 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
slave_until_opts:
|
|
|
|
master_file_def
|
|
|
|
| slave_until_opts ',' master_file_def ;
|
|
|
|
|
|
|
|
|
2000-09-15 00:34:50 +02:00
|
|
|
restore:
|
|
|
|
RESTORE_SYM table_or_tables
|
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_RESTORE_TABLE;
|
|
|
|
}
|
2003-03-17 18:56:34 +01:00
|
|
|
table_list FROM TEXT_STRING_sys
|
2000-09-15 00:34:50 +02:00
|
|
|
{
|
|
|
|
Lex->backup_dir = $6.str;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2002-07-23 17:31:22 +02:00
|
|
|
|
2000-09-15 00:34:50 +02:00
|
|
|
backup:
|
|
|
|
BACKUP_SYM table_or_tables
|
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_BACKUP_TABLE;
|
|
|
|
}
|
2003-03-17 18:56:34 +01:00
|
|
|
table_list TO_SYM TEXT_STRING_sys
|
2000-09-15 00:34:50 +02:00
|
|
|
{
|
|
|
|
Lex->backup_dir = $6.str;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-09-15 00:34:50 +02:00
|
|
|
|
2003-08-21 16:15:06 +02:00
|
|
|
checksum:
|
|
|
|
CHECKSUM_SYM table_or_tables
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command = SQLCOM_CHECKSUM;
|
|
|
|
}
|
2003-09-03 11:34:32 +02:00
|
|
|
table_list opt_checksum_type
|
|
|
|
{}
|
2003-08-21 16:15:06 +02:00
|
|
|
;
|
|
|
|
|
2003-09-03 11:34:32 +02:00
|
|
|
opt_checksum_type:
|
|
|
|
/* nothing */ { Lex->check_opt.flags= 0; }
|
|
|
|
| QUICK { Lex->check_opt.flags= T_QUICK; }
|
|
|
|
| EXTENDED_SYM { Lex->check_opt.flags= T_EXTEND; }
|
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
repair:
|
2003-05-15 18:35:39 +02:00
|
|
|
REPAIR opt_no_write_to_binlog table_or_tables
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command = SQLCOM_REPAIR;
|
2003-05-15 18:35:39 +02:00
|
|
|
lex->no_write_to_binlog= $2;
|
2001-06-15 04:03:15 +02:00
|
|
|
lex->check_opt.init();
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
table_list opt_mi_repair_type
|
|
|
|
{}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-03-13 18:20:17 +01:00
|
|
|
opt_mi_repair_type:
|
2000-07-31 21:29:14 +02:00
|
|
|
/* empty */ { Lex->check_opt.flags = T_MEDIUM; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| mi_repair_types {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-03-13 18:20:17 +01:00
|
|
|
mi_repair_types:
|
|
|
|
mi_repair_type {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| mi_repair_type mi_repair_types {};
|
2000-10-10 23:06:37 +02:00
|
|
|
|
2002-03-13 18:20:17 +01:00
|
|
|
mi_repair_type:
|
2002-03-21 18:32:37 +01:00
|
|
|
QUICK { Lex->check_opt.flags|= T_QUICK; }
|
2000-08-17 00:05:02 +02:00
|
|
|
| EXTENDED_SYM { Lex->check_opt.flags|= T_EXTEND; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| USE_FRM { Lex->check_opt.sql_flags|= TT_USEFRM; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
analyze:
|
2003-05-15 18:35:39 +02:00
|
|
|
ANALYZE_SYM opt_no_write_to_binlog table_or_tables
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command = SQLCOM_ANALYZE;
|
2003-05-15 18:35:39 +02:00
|
|
|
lex->no_write_to_binlog= $2;
|
2001-06-15 04:03:15 +02:00
|
|
|
lex->check_opt.init();
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
table_list opt_mi_check_type
|
|
|
|
{}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-12-22 06:39:02 +01:00
|
|
|
binlog_base64_event:
|
|
|
|
BINLOG_SYM TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_BINLOG_BASE64_EVENT;
|
|
|
|
Lex->comment= $2;
|
|
|
|
}
|
2005-12-26 14:22:12 +01:00
|
|
|
;
|
2005-12-22 06:39:02 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
check:
|
2000-08-21 23:39:08 +02:00
|
|
|
CHECK_SYM table_or_tables
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2005-03-30 17:43:52 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
|
|
|
|
if (lex->sphead)
|
|
|
|
{
|
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "CHECK");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-03-30 17:43:52 +02:00
|
|
|
}
|
|
|
|
lex->sql_command = SQLCOM_CHECK;
|
|
|
|
lex->check_opt.init();
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
table_list opt_mi_check_type
|
|
|
|
{}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-03-13 18:20:17 +01:00
|
|
|
opt_mi_check_type:
|
|
|
|
/* empty */ { Lex->check_opt.flags = T_MEDIUM; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| mi_check_types {};
|
2002-03-13 18:20:17 +01:00
|
|
|
|
|
|
|
mi_check_types:
|
|
|
|
mi_check_type {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| mi_check_type mi_check_types {};
|
2002-03-13 18:20:17 +01:00
|
|
|
|
|
|
|
mi_check_type:
|
|
|
|
QUICK { Lex->check_opt.flags|= T_QUICK; }
|
|
|
|
| FAST_SYM { Lex->check_opt.flags|= T_FAST; }
|
|
|
|
| MEDIUM_SYM { Lex->check_opt.flags|= T_MEDIUM; }
|
|
|
|
| EXTENDED_SYM { Lex->check_opt.flags|= T_EXTEND; }
|
2006-02-17 07:52:32 +01:00
|
|
|
| CHANGED { Lex->check_opt.flags|= T_CHECK_ONLY_CHANGED; }
|
|
|
|
| FOR_SYM UPGRADE_SYM { Lex->check_opt.sql_flags|= TT_FOR_UPGRADE; };
|
2002-03-13 18:20:17 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
optimize:
|
2003-05-15 18:35:39 +02:00
|
|
|
OPTIMIZE opt_no_write_to_binlog table_or_tables
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command = SQLCOM_OPTIMIZE;
|
2003-08-11 21:44:43 +02:00
|
|
|
lex->no_write_to_binlog= $2;
|
2001-06-15 04:03:15 +02:00
|
|
|
lex->check_opt.init();
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
table_list opt_mi_check_type
|
|
|
|
{}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-05-15 18:35:39 +02:00
|
|
|
opt_no_write_to_binlog:
|
|
|
|
/* empty */ { $$= 0; }
|
|
|
|
| NO_WRITE_TO_BINLOG { $$= 1; }
|
2003-05-16 15:28:17 +02:00
|
|
|
| LOCAL_SYM { $$= 1; }
|
2003-05-15 18:35:39 +02:00
|
|
|
;
|
|
|
|
|
2000-08-21 02:00:52 +02:00
|
|
|
rename:
|
|
|
|
RENAME table_or_tables
|
|
|
|
{
|
2005-11-16 13:09:06 +01:00
|
|
|
Lex->sql_command= SQLCOM_RENAME_TABLE;
|
2000-08-21 02:00:52 +02:00
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
table_to_table_list
|
|
|
|
{}
|
2006-02-13 08:49:28 +01:00
|
|
|
| RENAME DATABASE
|
|
|
|
{
|
|
|
|
Lex->db_list.empty();
|
|
|
|
Lex->sql_command= SQLCOM_RENAME_DB;
|
|
|
|
}
|
|
|
|
db_to_db
|
|
|
|
{}
|
2004-11-25 21:55:49 +01:00
|
|
|
| RENAME USER clear_privileges rename_list
|
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_RENAME_USER;
|
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
;
|
2000-08-21 02:00:52 +02:00
|
|
|
|
2004-11-25 21:55:49 +01:00
|
|
|
rename_list:
|
|
|
|
user TO_SYM user
|
|
|
|
{
|
|
|
|
if (Lex->users_list.push_back($1) || Lex->users_list.push_back($3))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-25 21:55:49 +01:00
|
|
|
}
|
|
|
|
| rename_list ',' user TO_SYM user
|
|
|
|
{
|
|
|
|
if (Lex->users_list.push_back($3) || Lex->users_list.push_back($5))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-25 21:55:49 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2000-08-21 02:00:52 +02:00
|
|
|
table_to_table_list:
|
|
|
|
table_to_table
|
2002-04-16 01:09:30 +02:00
|
|
|
| table_to_table_list ',' table_to_table;
|
2000-08-21 02:00:52 +02:00
|
|
|
|
|
|
|
table_to_table:
|
|
|
|
table_ident TO_SYM table_ident
|
2002-11-29 16:17:52 +01:00
|
|
|
{
|
2003-08-11 21:44:43 +02:00
|
|
|
LEX *lex=Lex;
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sl= lex->current_select;
|
2003-01-09 02:55:26 +01:00
|
|
|
if (!sl->add_table_to_list(lex->thd, $1,NULL,TL_OPTION_UPDATING,
|
|
|
|
TL_IGNORE) ||
|
|
|
|
!sl->add_table_to_list(lex->thd, $3,NULL,TL_OPTION_UPDATING,
|
|
|
|
TL_IGNORE))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-11-29 16:17:52 +01:00
|
|
|
};
|
2000-08-21 02:00:52 +02:00
|
|
|
|
2006-02-13 08:49:28 +01:00
|
|
|
db_to_db:
|
|
|
|
ident TO_SYM ident
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2007-01-29 00:47:35 +01:00
|
|
|
if (lex->db_list.push_back((LEX_STRING*)
|
2006-02-13 08:49:28 +01:00
|
|
|
sql_memdup(&$1, sizeof(LEX_STRING))) ||
|
2007-01-29 00:47:35 +01:00
|
|
|
lex->db_list.push_back((LEX_STRING*)
|
2006-02-13 08:49:28 +01:00
|
|
|
sql_memdup(&$3, sizeof(LEX_STRING))))
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-02-13 08:49:28 +01:00
|
|
|
};
|
|
|
|
|
2003-08-26 09:15:49 +02:00
|
|
|
keycache:
|
2004-06-23 12:29:05 +02:00
|
|
|
CACHE_SYM INDEX_SYM keycache_list IN_SYM key_cache_name
|
2003-08-26 09:15:49 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2003-11-18 12:47:27 +01:00
|
|
|
lex->sql_command= SQLCOM_ASSIGN_TO_KEYCACHE;
|
2005-01-16 13:16:23 +01:00
|
|
|
lex->ident= $5;
|
2003-08-26 09:15:49 +02:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
keycache_list:
|
|
|
|
assign_to_keycache
|
|
|
|
| keycache_list ',' assign_to_keycache;
|
|
|
|
|
|
|
|
assign_to_keycache:
|
2003-11-18 12:47:27 +01:00
|
|
|
table_ident cache_keys_spec
|
2003-08-26 09:15:49 +02:00
|
|
|
{
|
2007-03-05 18:08:41 +01:00
|
|
|
if (!Select->add_table_to_list(YYTHD, $1, NULL, 0, TL_READ,
|
|
|
|
Select->pop_index_hints()))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-08-26 09:15:49 +02:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2003-11-18 12:47:27 +01:00
|
|
|
key_cache_name:
|
|
|
|
ident { $$= $1; }
|
|
|
|
| DEFAULT { $$ = default_key_cache_base; }
|
2003-11-18 22:47:04 +01:00
|
|
|
;
|
2003-11-18 12:47:27 +01:00
|
|
|
|
2003-06-12 13:29:02 +02:00
|
|
|
preload:
|
2004-06-23 12:29:05 +02:00
|
|
|
LOAD INDEX_SYM INTO CACHE_SYM
|
2003-06-12 13:29:02 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command=SQLCOM_PRELOAD_KEYS;
|
|
|
|
}
|
|
|
|
preload_list
|
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
|
|
|
preload_list:
|
|
|
|
preload_keys
|
|
|
|
| preload_list ',' preload_keys;
|
|
|
|
|
|
|
|
preload_keys:
|
2003-08-26 09:15:49 +02:00
|
|
|
table_ident cache_keys_spec opt_ignore_leaves
|
2003-06-12 13:29:02 +02:00
|
|
|
{
|
2007-03-05 18:08:41 +01:00
|
|
|
if (!Select->add_table_to_list(YYTHD, $1, NULL, $3, TL_READ,
|
|
|
|
Select->pop_index_hints()))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-06-12 13:29:02 +02:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2003-08-27 00:14:13 +02:00
|
|
|
cache_keys_spec:
|
|
|
|
{
|
2007-03-05 18:08:41 +01:00
|
|
|
Lex->select_lex.alloc_index_hints(YYTHD);
|
|
|
|
Select->set_index_hint_type(INDEX_HINT_USE,
|
|
|
|
global_system_variables.old_mode ?
|
|
|
|
INDEX_HINT_MASK_JOIN :
|
|
|
|
INDEX_HINT_MASK_ALL);
|
2003-08-27 00:14:13 +02:00
|
|
|
}
|
2007-03-05 18:08:41 +01:00
|
|
|
cache_key_list_or_empty
|
2003-08-27 00:14:13 +02:00
|
|
|
;
|
2003-06-12 13:29:02 +02:00
|
|
|
|
2003-08-26 09:15:49 +02:00
|
|
|
cache_key_list_or_empty:
|
2007-03-05 18:08:41 +01:00
|
|
|
/* empty */ { }
|
|
|
|
| key_or_index '(' opt_key_usage_list ')'
|
2003-06-12 13:29:02 +02:00
|
|
|
;
|
|
|
|
|
2003-06-19 11:34:33 +02:00
|
|
|
opt_ignore_leaves:
|
2003-06-12 13:29:02 +02:00
|
|
|
/* empty */
|
|
|
|
{ $$= 0; }
|
|
|
|
| IGNORE_SYM LEAVES { $$= TL_OPTION_IGNORE_LEAVES; }
|
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/*
|
2001-12-17 18:59:20 +01:00
|
|
|
Select : retrieve data from table
|
2000-07-31 21:29:14 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
select:
|
2003-07-29 15:59:46 +02:00
|
|
|
select_init
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
2003-08-12 16:40:11 +02:00
|
|
|
}
|
|
|
|
;
|
2001-12-13 01:31:19 +01:00
|
|
|
|
2002-11-28 16:10:29 +01:00
|
|
|
/* Need select_init2 for subselects. */
|
2001-12-13 01:31:19 +01:00
|
|
|
select_init:
|
2002-11-28 16:10:29 +01:00
|
|
|
SELECT_SYM select_init2
|
2001-10-25 13:41:49 +02:00
|
|
|
|
|
2005-02-13 23:35:52 +01:00
|
|
|
'(' select_paren ')' union_opt;
|
|
|
|
|
|
|
|
select_paren:
|
|
|
|
SELECT_SYM select_part2
|
2002-11-29 16:17:52 +01:00
|
|
|
{
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX *lex= Lex;
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX * sel= lex->current_select;
|
2002-12-05 18:38:42 +01:00
|
|
|
if (sel->set_braces(1))
|
2002-10-30 12:18:52 +01:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2002-10-30 12:18:52 +01:00
|
|
|
}
|
2006-08-31 17:00:25 +02:00
|
|
|
if (sel->linkage == UNION_TYPE &&
|
|
|
|
!sel->master_unit()->first_select()->braces &&
|
|
|
|
sel->master_unit()->first_select()->linkage ==
|
|
|
|
UNION_TYPE)
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2006-08-31 17:00:25 +02:00
|
|
|
}
|
2002-05-08 22:14:40 +02:00
|
|
|
/* select in braces, can't contain global parameters */
|
2003-09-09 14:23:38 +02:00
|
|
|
if (sel->master_unit()->fake_select_lex)
|
|
|
|
sel->master_unit()->global_parameters=
|
|
|
|
sel->master_unit()->fake_select_lex;
|
2005-02-13 23:35:52 +01:00
|
|
|
}
|
|
|
|
| '(' select_paren ')';
|
2001-08-14 19:33:49 +02:00
|
|
|
|
2002-11-28 16:10:29 +01:00
|
|
|
select_init2:
|
|
|
|
select_part2
|
2002-11-29 16:17:52 +01:00
|
|
|
{
|
2002-11-28 16:10:29 +01:00
|
|
|
LEX *lex= Lex;
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX * sel= lex->current_select;
|
2002-12-05 18:38:42 +01:00
|
|
|
if (lex->current_select->set_braces(0))
|
2002-11-28 16:10:29 +01:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2002-11-28 16:10:29 +01:00
|
|
|
}
|
2003-02-12 20:55:37 +01:00
|
|
|
if (sel->linkage == UNION_TYPE &&
|
|
|
|
sel->master_unit()->first_select()->braces)
|
2002-12-24 12:58:07 +01:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2002-12-24 12:58:07 +01:00
|
|
|
}
|
2002-11-28 16:10:29 +01:00
|
|
|
}
|
2002-11-28 17:25:41 +01:00
|
|
|
union_clause
|
2002-11-28 16:10:29 +01:00
|
|
|
;
|
|
|
|
|
2001-08-14 19:33:49 +02:00
|
|
|
select_part2:
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-02-09 12:31:03 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
SELECT_LEX *sel= lex->current_select;
|
2003-02-13 16:56:01 +01:00
|
|
|
if (sel->linkage != UNION_TYPE)
|
|
|
|
mysql_init_select(lex);
|
2004-08-13 09:01:30 +02:00
|
|
|
lex->current_select->parsing_place= SELECT_LIST;
|
2003-05-17 09:05:07 +02:00
|
|
|
}
|
|
|
|
select_options select_item_list
|
|
|
|
{
|
2004-08-13 09:01:30 +02:00
|
|
|
Select->parsing_place= NO_MATTER;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2003-05-17 09:05:07 +02:00
|
|
|
select_into select_lock_type;
|
2001-10-19 16:43:30 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
select_into:
|
2005-04-26 20:27:06 +02:00
|
|
|
opt_order_clause opt_limit_clause {}
|
2002-11-28 17:25:41 +01:00
|
|
|
| into
|
2000-07-31 21:29:14 +02:00
|
|
|
| select_from
|
2002-11-28 17:25:41 +01:00
|
|
|
| into select_from
|
|
|
|
| select_from into;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
select_from:
|
2004-05-19 14:51:41 +02:00
|
|
|
FROM join_table_list where_clause group_clause having_clause
|
|
|
|
opt_order_clause opt_limit_clause procedure_clause
|
2007-02-19 13:39:37 +01:00
|
|
|
{
|
|
|
|
Select->context.table_list=
|
|
|
|
Select->context.first_name_resolution_table=
|
|
|
|
(TABLE_LIST *) Select->table_list.first;
|
|
|
|
}
|
2005-07-17 18:46:14 +02:00
|
|
|
| FROM DUAL_SYM where_clause opt_limit_clause
|
2005-02-02 07:38:24 +01:00
|
|
|
/* oracle compatibility: oracle always requires FROM clause,
|
|
|
|
and DUAL is system table without fields.
|
|
|
|
Is "SELECT 1 FROM DUAL" any better than "SELECT 1" ?
|
|
|
|
Hmmm :) */
|
2004-05-19 14:51:41 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
select_options:
|
|
|
|
/* empty*/
|
2005-05-13 13:04:32 +02:00
|
|
|
| select_option_list
|
|
|
|
{
|
2005-06-13 15:14:41 +02:00
|
|
|
if (Select->options & SELECT_DISTINCT && Select->options & SELECT_ALL)
|
2005-05-13 13:04:32 +02:00
|
|
|
{
|
2005-05-16 14:21:35 +02:00
|
|
|
my_error(ER_WRONG_USAGE, MYF(0), "ALL", "DISTINCT");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-05-13 13:04:32 +02:00
|
|
|
}
|
|
|
|
}
|
2005-05-17 22:52:36 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
select_option_list:
|
|
|
|
select_option_list select_option
|
2002-04-16 01:09:30 +02:00
|
|
|
| select_option;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
select_option:
|
2001-06-03 16:07:26 +02:00
|
|
|
STRAIGHT_JOIN { Select->options|= SELECT_STRAIGHT_JOIN; }
|
2002-07-24 18:55:08 +02:00
|
|
|
| HIGH_PRIORITY
|
|
|
|
{
|
|
|
|
if (check_simple_select())
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-07-24 18:55:08 +02:00
|
|
|
Lex->lock_option= TL_READ_HIGH_PRIORITY;
|
|
|
|
}
|
2005-05-13 13:04:32 +02:00
|
|
|
| DISTINCT { Select->options|= SELECT_DISTINCT; }
|
2001-06-03 16:07:26 +02:00
|
|
|
| SQL_SMALL_RESULT { Select->options|= SELECT_SMALL_RESULT; }
|
|
|
|
| SQL_BIG_RESULT { Select->options|= SELECT_BIG_RESULT; }
|
2002-07-24 18:55:08 +02:00
|
|
|
| SQL_BUFFER_RESULT
|
|
|
|
{
|
|
|
|
if (check_simple_select())
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-07-24 18:55:08 +02:00
|
|
|
Select->options|= OPTION_BUFFER_RESULT;
|
|
|
|
}
|
|
|
|
| SQL_CALC_FOUND_ROWS
|
|
|
|
{
|
|
|
|
if (check_simple_select())
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-07-24 18:55:08 +02:00
|
|
|
Select->options|= OPTION_FOUND_ROWS;
|
|
|
|
}
|
2006-06-27 19:28:32 +02:00
|
|
|
| SQL_NO_CACHE_SYM
|
|
|
|
{
|
|
|
|
Lex->safe_to_cache_query=0;
|
|
|
|
Lex->select_lex.options&= ~OPTION_TO_QUERY_CACHE;
|
|
|
|
Lex->select_lex.sql_cache= SELECT_LEX::SQL_NO_CACHE;
|
|
|
|
}
|
2003-02-27 21:26:09 +01:00
|
|
|
| SQL_CACHE_SYM
|
|
|
|
{
|
2007-06-18 23:16:20 +02:00
|
|
|
/*
|
|
|
|
Honor this flag only if SQL_NO_CACHE wasn't specified AND
|
|
|
|
we are parsing the outermost SELECT in the query.
|
|
|
|
*/
|
|
|
|
if (Lex->select_lex.sql_cache != SELECT_LEX::SQL_NO_CACHE &&
|
|
|
|
Lex->current_select == &Lex->select_lex)
|
2006-06-27 19:28:32 +02:00
|
|
|
{
|
|
|
|
Lex->safe_to_cache_query=1;
|
|
|
|
Lex->select_lex.options|= OPTION_TO_QUERY_CACHE;
|
|
|
|
Lex->select_lex.sql_cache= SELECT_LEX::SQL_CACHE;
|
|
|
|
}
|
2003-02-27 21:26:09 +01:00
|
|
|
}
|
2005-06-13 15:14:41 +02:00
|
|
|
| ALL { Select->options|= SELECT_ALL; }
|
2002-07-24 18:55:08 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-03-21 00:02:22 +01:00
|
|
|
select_lock_type:
|
|
|
|
/* empty */
|
|
|
|
| FOR_SYM UPDATE_SYM
|
2002-07-24 18:55:08 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2002-11-25 12:44:47 +01:00
|
|
|
lex->current_select->set_lock_for_tables(TL_WRITE);
|
2002-11-22 14:50:53 +01:00
|
|
|
lex->safe_to_cache_query=0;
|
2002-07-24 18:55:08 +02:00
|
|
|
}
|
2001-12-11 19:45:48 +01:00
|
|
|
| LOCK_SYM IN_SYM SHARE_SYM MODE_SYM
|
2002-07-24 18:55:08 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2002-11-25 12:44:47 +01:00
|
|
|
lex->current_select->
|
|
|
|
set_lock_for_tables(TL_READ_WITH_SHARED_LOCKS);
|
2002-11-22 14:50:53 +01:00
|
|
|
lex->safe_to_cache_query=0;
|
2002-07-24 18:55:08 +02:00
|
|
|
}
|
|
|
|
;
|
2001-03-21 00:02:22 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
select_item_list:
|
|
|
|
select_item_list ',' select_item
|
|
|
|
| select_item
|
|
|
|
| '*'
|
|
|
|
{
|
2003-01-25 01:25:52 +01:00
|
|
|
THD *thd= YYTHD;
|
2005-07-01 06:05:42 +02:00
|
|
|
if (add_item_to_list(thd,
|
|
|
|
new Item_field(&thd->lex->current_select->
|
|
|
|
context,
|
|
|
|
NULL, NULL, "*")))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-12-19 18:52:13 +01:00
|
|
|
(thd->lex->current_select->with_wild)++;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
select_item:
|
|
|
|
remember_name select_item2 remember_end select_alias
|
|
|
|
{
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
DBUG_ASSERT($1 < $3);
|
|
|
|
|
|
|
|
if (add_item_to_list(thd, $2))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
if ($4.str)
|
2005-06-21 19:30:48 +02:00
|
|
|
{
|
|
|
|
$2->is_autogenerated_name= FALSE;
|
2006-07-15 22:45:38 +02:00
|
|
|
$2->set_name($4.str, $4.length, system_charset_info);
|
2005-06-21 19:30:48 +02:00
|
|
|
}
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
else if (!$2->name)
|
|
|
|
{
|
|
|
|
$2->set_name($1, (uint) ($3 - $1), thd->charset());
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.
This line of code in sql_lex.cc :
case MY_LEX_USER_VARIABLE_DELIMITER:
lip->tok_start= lip->ptr; // Skip first `
would <skip the first back quote> ... and cause the bug reported.
In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).
With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).
The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.
This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:
The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)
If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-28 01:14:25 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
remember_name:
|
2007-04-26 05:38:12 +02:00
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
$$= (char*) lip->get_cpp_tok_start();
|
2007-04-26 05:38:12 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
remember_end:
|
2007-04-26 05:38:12 +02:00
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
$$= (char*) lip->get_cpp_tok_end();
|
2007-04-26 05:38:12 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
select_item2:
|
|
|
|
table_wild { $$=$1; } /* table.* */
|
2002-04-16 01:09:30 +02:00
|
|
|
| expr { $$=$1; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
select_alias:
|
2005-01-16 13:16:23 +01:00
|
|
|
/* empty */ { $$=null_lex_str;}
|
2003-03-17 18:56:34 +01:00
|
|
|
| AS ident { $$=$2; }
|
|
|
|
| AS TEXT_STRING_sys { $$=$2; }
|
|
|
|
| ident { $$=$1; }
|
|
|
|
| TEXT_STRING_sys { $$=$1; }
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
optional_braces:
|
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| '(' ')' {};
|
2000-08-21 23:39:08 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/* all possible expressions */
|
2003-01-21 17:20:46 +01:00
|
|
|
expr:
|
2005-03-16 01:13:23 +01:00
|
|
|
bool_term { Select->expr_list.push_front(new List<Item>); }
|
|
|
|
bool_or_expr
|
|
|
|
{
|
|
|
|
List<Item> *list= Select->expr_list.pop();
|
|
|
|
if (list->elements)
|
|
|
|
{
|
|
|
|
list->push_front($1);
|
|
|
|
$$= new Item_cond_or(*list);
|
|
|
|
/* optimize construction of logical OR to reduce
|
|
|
|
amount of objects for complex expressions */
|
|
|
|
}
|
|
|
|
else
|
|
|
|
$$= $1;
|
|
|
|
delete list;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
bool_or_expr:
|
|
|
|
/* empty */
|
|
|
|
| bool_or_expr or bool_term
|
|
|
|
{ Select->expr_list.head()->push_back($3); }
|
|
|
|
;
|
2004-11-17 16:49:10 +01:00
|
|
|
|
|
|
|
bool_term:
|
2005-03-16 01:13:23 +01:00
|
|
|
bool_term XOR bool_term { $$= new Item_cond_xor($1,$3); }
|
|
|
|
| bool_factor { Select->expr_list.push_front(new List<Item>); }
|
|
|
|
bool_and_expr
|
|
|
|
{
|
|
|
|
List<Item> *list= Select->expr_list.pop();
|
|
|
|
if (list->elements)
|
|
|
|
{
|
|
|
|
list->push_front($1);
|
|
|
|
$$= new Item_cond_and(*list);
|
|
|
|
/* optimize construction of logical AND to reduce
|
|
|
|
amount of objects for complex expressions */
|
|
|
|
}
|
|
|
|
else
|
|
|
|
$$= $1;
|
|
|
|
delete list;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
bool_and_expr:
|
|
|
|
/* empty */
|
|
|
|
| bool_and_expr and bool_factor
|
|
|
|
{ Select->expr_list.head()->push_back($3); }
|
|
|
|
;
|
2004-11-17 16:49:10 +01:00
|
|
|
|
|
|
|
bool_factor:
|
|
|
|
NOT_SYM bool_factor { $$= negate_expression(YYTHD, $2); }
|
|
|
|
| bool_test ;
|
|
|
|
|
|
|
|
bool_test:
|
2007-02-13 01:20:41 +01:00
|
|
|
bool_pri IS TRUE_SYM
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_istrue($1); }
|
|
|
|
| bool_pri IS not TRUE_SYM
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_isnottrue($1); }
|
|
|
|
| bool_pri IS FALSE_SYM
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_isfalse($1); }
|
|
|
|
| bool_pri IS not FALSE_SYM
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_isnotfalse($1); }
|
2004-11-17 16:49:10 +01:00
|
|
|
| bool_pri IS UNKNOWN_SYM { $$= new Item_func_isnull($1); }
|
|
|
|
| bool_pri IS not UNKNOWN_SYM { $$= new Item_func_isnotnull($1); }
|
2007-02-13 01:20:41 +01:00
|
|
|
| bool_pri
|
|
|
|
;
|
2004-11-17 16:49:10 +01:00
|
|
|
|
|
|
|
bool_pri:
|
|
|
|
bool_pri IS NULL_SYM { $$= new Item_func_isnull($1); }
|
|
|
|
| bool_pri IS not NULL_SYM { $$= new Item_func_isnotnull($1); }
|
2005-02-04 00:08:43 +01:00
|
|
|
| bool_pri EQUAL_SYM predicate { $$= new Item_func_equal($1,$3); }
|
|
|
|
| bool_pri comp_op predicate %prec EQ
|
|
|
|
{ $$= (*$2)(0)->create($1,$3); }
|
2006-08-31 17:00:25 +02:00
|
|
|
| bool_pri comp_op all_or_any '(' subselect ')' %prec EQ
|
|
|
|
{ $$= all_any_subquery_creator($1, $2, $3, $5); }
|
2004-11-17 16:49:10 +01:00
|
|
|
| predicate ;
|
|
|
|
|
|
|
|
predicate:
|
2006-08-31 17:00:25 +02:00
|
|
|
bit_expr IN_SYM '(' subselect ')'
|
2007-01-30 01:32:52 +01:00
|
|
|
{
|
|
|
|
$$= new (YYTHD->mem_root) Item_in_subselect($1, $4);
|
|
|
|
}
|
2006-08-31 17:00:25 +02:00
|
|
|
| bit_expr not IN_SYM '(' subselect ')'
|
2007-01-30 01:32:52 +01:00
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
Item *item= new (thd->mem_root) Item_in_subselect($1, $5);
|
|
|
|
$$= negate_expression(thd, item);
|
|
|
|
}
|
2006-08-31 17:00:25 +02:00
|
|
|
| bit_expr IN_SYM '(' expr ')'
|
|
|
|
{
|
2007-01-30 01:32:52 +01:00
|
|
|
$$= handle_sql2003_note184_exception(YYTHD, $1, true, $4);
|
2006-08-31 17:00:25 +02:00
|
|
|
}
|
|
|
|
| bit_expr IN_SYM '(' expr ',' expr_list ')'
|
2005-07-17 03:06:34 +02:00
|
|
|
{
|
2006-08-31 17:00:25 +02:00
|
|
|
$6->push_front($4);
|
|
|
|
$6->push_front($1);
|
2007-01-30 01:32:52 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_func_in(*$6);
|
2005-07-17 03:06:34 +02:00
|
|
|
}
|
2006-08-31 17:00:25 +02:00
|
|
|
| bit_expr not IN_SYM '(' expr ')'
|
2005-07-17 03:06:34 +02:00
|
|
|
{
|
2007-01-30 01:32:52 +01:00
|
|
|
$$= handle_sql2003_note184_exception(YYTHD, $1, false, $5);
|
2006-08-31 17:00:25 +02:00
|
|
|
}
|
|
|
|
| bit_expr not IN_SYM '(' expr ',' expr_list ')'
|
|
|
|
{
|
|
|
|
$7->push_front($5);
|
|
|
|
$7->push_front($1);
|
2007-01-30 01:32:52 +01:00
|
|
|
Item_func_in *item = new (YYTHD->mem_root) Item_func_in(*$7);
|
2005-09-07 15:42:47 +02:00
|
|
|
item->negate();
|
|
|
|
$$= item;
|
2005-07-17 03:06:34 +02:00
|
|
|
}
|
2005-02-04 00:08:43 +01:00
|
|
|
| bit_expr BETWEEN_SYM bit_expr AND_SYM predicate
|
|
|
|
{ $$= new Item_func_between($1,$3,$5); }
|
|
|
|
| bit_expr not BETWEEN_SYM bit_expr AND_SYM predicate
|
2005-09-07 15:42:47 +02:00
|
|
|
{
|
|
|
|
Item_func_between *item= new Item_func_between($1,$4,$6);
|
|
|
|
item->negate();
|
|
|
|
$$= item;
|
|
|
|
}
|
2004-11-17 16:49:10 +01:00
|
|
|
| bit_expr SOUNDS_SYM LIKE bit_expr
|
|
|
|
{ $$= new Item_func_eq(new Item_func_soundex($1),
|
|
|
|
new Item_func_soundex($4)); }
|
|
|
|
| bit_expr LIKE simple_expr opt_escape
|
2005-10-21 03:01:52 +02:00
|
|
|
{ $$= new Item_func_like($1,$3,$4,Lex->escape_used); }
|
2004-11-17 16:49:10 +01:00
|
|
|
| bit_expr not LIKE simple_expr opt_escape
|
2005-10-21 03:01:52 +02:00
|
|
|
{ $$= new Item_func_not(new Item_func_like($1,$4,$5, Lex->escape_used)); }
|
2004-11-17 16:49:10 +01:00
|
|
|
| bit_expr REGEXP bit_expr { $$= new Item_func_regex($1,$3); }
|
|
|
|
| bit_expr not REGEXP bit_expr
|
2004-11-17 16:49:12 +01:00
|
|
|
{ $$= negate_expression(YYTHD, new Item_func_regex($1,$4)); }
|
2004-11-17 16:49:10 +01:00
|
|
|
| bit_expr ;
|
|
|
|
|
|
|
|
bit_expr:
|
|
|
|
bit_expr '|' bit_term { $$= new Item_func_bit_or($1,$3); }
|
|
|
|
| bit_term ;
|
|
|
|
|
|
|
|
bit_term:
|
|
|
|
bit_term '&' bit_factor { $$= new Item_func_bit_and($1,$3); }
|
|
|
|
| bit_factor ;
|
|
|
|
|
|
|
|
bit_factor:
|
|
|
|
bit_factor SHIFT_LEFT value_expr
|
|
|
|
{ $$= new Item_func_shift_left($1,$3); }
|
|
|
|
| bit_factor SHIFT_RIGHT value_expr
|
|
|
|
{ $$= new Item_func_shift_right($1,$3); }
|
|
|
|
| value_expr ;
|
|
|
|
|
|
|
|
value_expr:
|
|
|
|
value_expr '+' term { $$= new Item_func_plus($1,$3); }
|
|
|
|
| value_expr '-' term { $$= new Item_func_minus($1,$3); }
|
|
|
|
| value_expr '+' interval_expr interval
|
|
|
|
{ $$= new Item_date_add_interval($1,$3,$4,0); }
|
|
|
|
| value_expr '-' interval_expr interval
|
|
|
|
{ $$= new Item_date_add_interval($1,$3,$4,1); }
|
|
|
|
| term ;
|
|
|
|
|
|
|
|
term:
|
|
|
|
term '*' factor { $$= new Item_func_mul($1,$3); }
|
|
|
|
| term '/' factor { $$= new Item_func_div($1,$3); }
|
|
|
|
| term '%' factor { $$= new Item_func_mod($1,$3); }
|
|
|
|
| term DIV_SYM factor { $$= new Item_func_int_div($1,$3); }
|
|
|
|
| term MOD_SYM factor { $$= new Item_func_mod($1,$3); }
|
|
|
|
| factor ;
|
|
|
|
|
|
|
|
factor:
|
|
|
|
factor '^' simple_expr { $$= new Item_func_bit_xor($1,$3); }
|
|
|
|
| simple_expr ;
|
|
|
|
|
|
|
|
or: OR_SYM | OR2_SYM;
|
|
|
|
and: AND_SYM | AND_AND_SYM;
|
|
|
|
not: NOT_SYM | NOT2_SYM;
|
|
|
|
not2: '!' | NOT2_SYM;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-11-07 22:45:19 +01:00
|
|
|
comp_op: EQ { $$ = &comp_eq_creator; }
|
|
|
|
| GE { $$ = &comp_ge_creator; }
|
|
|
|
| GT_SYM { $$ = &comp_gt_creator; }
|
|
|
|
| LE { $$ = &comp_le_creator; }
|
|
|
|
| LT { $$ = &comp_lt_creator; }
|
|
|
|
| NE { $$ = &comp_ne_creator; }
|
|
|
|
;
|
|
|
|
|
|
|
|
all_or_any: ALL { $$ = 1; }
|
|
|
|
| ANY_SYM { $$ = 0; }
|
|
|
|
;
|
|
|
|
|
2003-01-26 20:01:45 +01:00
|
|
|
interval_expr:
|
2003-01-27 10:46:33 +01:00
|
|
|
INTERVAL_SYM expr { $$=$2; }
|
2003-01-26 20:01:45 +01:00
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
simple_expr:
|
|
|
|
simple_ident
|
2006-11-02 19:01:53 +01:00
|
|
|
| function_call_keyword
|
|
|
|
| function_call_nonkeyword
|
|
|
|
| function_call_generic
|
|
|
|
| function_call_conflict
|
2003-03-21 09:04:08 +01:00
|
|
|
| simple_expr COLLATE_SYM ident_or_text %prec NEG
|
2003-08-11 21:44:43 +02:00
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
Item *i1= new (thd->mem_root) Item_string($3.str,
|
|
|
|
$3.length,
|
|
|
|
thd->charset());
|
|
|
|
$$= new (thd->mem_root) Item_func_set_collation($1, i1);
|
2003-03-21 09:04:08 +01:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| literal
|
2002-06-12 23:13:12 +02:00
|
|
|
| param_marker
|
2006-10-12 16:02:57 +02:00
|
|
|
| variable
|
2000-07-31 21:29:14 +02:00
|
|
|
| sum_expr
|
2004-11-17 16:49:10 +01:00
|
|
|
| simple_expr OR_OR_SYM simple_expr
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_concat($1, $3); }
|
2004-11-17 16:49:10 +01:00
|
|
|
| '+' simple_expr %prec NEG { $$= $2; }
|
2006-11-02 19:01:53 +01:00
|
|
|
| '-' simple_expr %prec NEG
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_neg($2); }
|
|
|
|
| '~' simple_expr %prec NEG
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_bit_neg($2); }
|
|
|
|
| not2 simple_expr %prec NEG
|
|
|
|
{ $$= negate_expression(YYTHD, $2); }
|
2006-08-31 17:00:25 +02:00
|
|
|
| '(' subselect ')'
|
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_singlerow_subselect($2);
|
2006-08-31 17:00:25 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| '(' expr ')' { $$= $2; }
|
2003-01-26 20:01:45 +01:00
|
|
|
| '(' expr ',' expr_list ')'
|
|
|
|
{
|
|
|
|
$4->push_front($2);
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_row(*$4);
|
2003-01-26 20:01:45 +01:00
|
|
|
}
|
2002-11-30 19:33:01 +01:00
|
|
|
| ROW_SYM '(' expr ',' expr_list ')'
|
2002-11-15 19:32:09 +01:00
|
|
|
{
|
2002-11-30 19:33:01 +01:00
|
|
|
$5->push_front($3);
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_row(*$5);
|
2002-11-15 19:32:09 +01:00
|
|
|
}
|
2006-08-31 17:00:25 +02:00
|
|
|
| EXISTS '(' subselect ')'
|
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_exists_subselect($3);
|
2006-08-31 17:00:25 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| '{' ident expr '}' { $$= $3; }
|
2004-11-17 16:49:10 +01:00
|
|
|
| MATCH ident_list_arg AGAINST '(' bit_expr fulltext_options ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{
|
|
|
|
$2->push_front($5);
|
|
|
|
Item_func_match *i1= new (YYTHD->mem_root) Item_func_match(*$2, $6);
|
|
|
|
Select->add_ftfunc_to_list(i1);
|
|
|
|
$$= i1;
|
|
|
|
}
|
2004-11-17 16:49:10 +01:00
|
|
|
| BINARY simple_expr %prec NEG
|
2003-03-04 16:53:53 +01:00
|
|
|
{
|
2007-05-11 10:07:53 +02:00
|
|
|
$$= create_func_cast(YYTHD, $2, ITEM_CAST_CHAR, NULL, NULL,
|
2006-11-02 19:01:53 +01:00
|
|
|
&my_charset_bin);
|
2003-03-04 16:53:53 +01:00
|
|
|
}
|
2003-05-28 14:57:58 +02:00
|
|
|
| CAST_SYM '(' expr AS cast_type ')'
|
2003-10-20 15:53:48 +02:00
|
|
|
{
|
2005-02-08 23:50:45 +01:00
|
|
|
LEX *lex= Lex;
|
2007-05-11 10:07:53 +02:00
|
|
|
$$= create_func_cast(YYTHD, $3, $5, lex->length, lex->dec,
|
2005-02-08 23:50:45 +01:00
|
|
|
lex->charset);
|
2006-08-08 11:40:07 +02:00
|
|
|
if (!$$)
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-08-21 11:15:25 +02:00
|
|
|
}
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
| CASE_SYM opt_expr when_list opt_else END
|
2006-12-12 21:50:55 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_case(* $3, $2, $4 ); }
|
2003-05-28 14:57:58 +02:00
|
|
|
| CONVERT_SYM '(' expr ',' cast_type ')'
|
2003-08-21 11:15:25 +02:00
|
|
|
{
|
2007-05-11 10:07:53 +02:00
|
|
|
$$= create_func_cast(YYTHD, $3, $5, Lex->length, Lex->dec,
|
|
|
|
Lex->charset);
|
2006-08-08 11:40:07 +02:00
|
|
|
if (!$$)
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-08-21 11:15:25 +02:00
|
|
|
}
|
2002-09-12 16:36:22 +02:00
|
|
|
| CONVERT_SYM '(' expr USING charset_name ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_conv_charset($3,$5); }
|
2003-01-05 11:07:24 +01:00
|
|
|
| DEFAULT '(' simple_ident ')'
|
2005-06-01 15:42:40 +02:00
|
|
|
{
|
|
|
|
if ($3->is_splocal())
|
|
|
|
{
|
|
|
|
Item_splocal *il= static_cast<Item_splocal *>($3);
|
|
|
|
|
2005-12-07 15:01:17 +01:00
|
|
|
my_error(ER_WRONG_COLUMN_NAME, MYF(0), il->my_name()->str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-06-01 15:42:40 +02:00
|
|
|
}
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_default_value(Lex->current_context(),
|
|
|
|
$3);
|
2005-06-01 15:42:40 +02:00
|
|
|
}
|
2005-12-08 22:58:59 +01:00
|
|
|
| VALUES '(' simple_ident_nospvar ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_insert_value(Lex->current_context(),
|
|
|
|
$3); }
|
|
|
|
| interval_expr interval '+' expr
|
|
|
|
/* we cannot put interval before - */
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_date_add_interval($4,$1,$2,0); }
|
|
|
|
| interval_expr
|
2004-01-15 18:06:22 +01:00
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
if ($1->type() != Item::ROW_ITEM)
|
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-11-02 19:01:53 +01:00
|
|
|
}
|
|
|
|
$$= new (YYTHD->mem_root) Item_func_interval((Item_row *)$1);
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
/*
|
|
|
|
Function call syntax using official SQL 2003 keywords.
|
|
|
|
Because the function name is an official token,
|
|
|
|
a dedicated grammar rule is needed in the parser.
|
|
|
|
There is no potential for conflicts
|
|
|
|
*/
|
|
|
|
function_call_keyword:
|
|
|
|
CHAR_SYM '(' expr_list ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_char(*$3); }
|
|
|
|
| CHAR_SYM '(' expr_list USING charset_name ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_char(*$3, $5); }
|
2004-04-06 12:00:51 +02:00
|
|
|
| CURRENT_USER optional_braces
|
2006-07-02 12:35:45 +02:00
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_func_current_user(Lex->current_context());
|
2006-07-02 12:35:45 +02:00
|
|
|
Lex->safe_to_cache_query= 0;
|
|
|
|
}
|
2003-06-23 09:56:44 +02:00
|
|
|
| DATE_SYM '(' expr ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_date_typecast($3); }
|
2003-06-23 09:56:44 +02:00
|
|
|
| DAY_SYM '(' expr ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_dayofmonth($3); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| HOUR_SYM '(' expr ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_hour($3); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| INSERT '(' expr ',' expr ',' expr ',' expr ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_insert($3,$5,$7,$9); }
|
|
|
|
| LEFT '(' expr ',' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_left($3,$5); }
|
|
|
|
| MINUTE_SYM '(' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_minute($3); }
|
|
|
|
| MONTH_SYM '(' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_month($3); }
|
|
|
|
| RIGHT '(' expr ',' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_right($3,$5); }
|
|
|
|
| SECOND_SYM '(' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_second($3); }
|
|
|
|
| TIME_SYM '(' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_time_typecast($3); }
|
|
|
|
| TIMESTAMP '(' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_datetime_typecast($3); }
|
|
|
|
| TIMESTAMP '(' expr ',' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_add_time($3, $5, 1, 0); }
|
|
|
|
| TRIM '(' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_trim($3); }
|
|
|
|
| TRIM '(' LEADING expr FROM expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_ltrim($6,$4); }
|
|
|
|
| TRIM '(' TRAILING expr FROM expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_rtrim($6,$4); }
|
|
|
|
| TRIM '(' BOTH expr FROM expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_trim($6,$4); }
|
|
|
|
| TRIM '(' LEADING FROM expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_ltrim($5); }
|
|
|
|
| TRIM '(' TRAILING FROM expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_rtrim($5); }
|
|
|
|
| TRIM '(' BOTH FROM expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_trim($5); }
|
|
|
|
| TRIM '(' expr FROM expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_trim($5,$3); }
|
|
|
|
| USER '(' ')'
|
2003-01-26 20:01:45 +01:00
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_func_user();
|
|
|
|
Lex->safe_to_cache_query=0;
|
2003-01-26 20:01:45 +01:00
|
|
|
}
|
2006-11-02 19:01:53 +01:00
|
|
|
| YEAR_SYM '(' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_year($3); }
|
|
|
|
;
|
|
|
|
|
|
|
|
/*
|
|
|
|
Function calls using non reserved keywords, with special syntaxic forms.
|
|
|
|
Dedicated grammar rules are needed because of the syntax,
|
|
|
|
but also have the potential to cause incompatibilities with other
|
|
|
|
parts of the language.
|
|
|
|
MAINTAINER:
|
|
|
|
The only reasons a function should be added here are:
|
|
|
|
- for compatibility reasons with another SQL syntax (CURDATE),
|
|
|
|
- for typing reasons (GET_FORMAT)
|
|
|
|
Any other 'Syntaxic sugar' enhancements should be *STRONGLY*
|
|
|
|
discouraged.
|
|
|
|
*/
|
|
|
|
function_call_nonkeyword:
|
|
|
|
ADDDATE_SYM '(' expr ',' expr ')'
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_date_add_interval($3, $5,
|
|
|
|
INTERVAL_DAY, 0);
|
|
|
|
}
|
|
|
|
| ADDDATE_SYM '(' expr ',' INTERVAL_SYM expr interval ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_date_add_interval($3, $6, $7, 0); }
|
|
|
|
| CURDATE optional_braces
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_func_curdate_local();
|
|
|
|
Lex->safe_to_cache_query=0;
|
|
|
|
}
|
|
|
|
| CURTIME optional_braces
|
|
|
|
{
|
|
|
|
$$= new (YYTHD->mem_root) Item_func_curtime_local();
|
|
|
|
Lex->safe_to_cache_query=0;
|
|
|
|
}
|
|
|
|
| CURTIME '(' expr ')'
|
2003-08-11 21:44:43 +02:00
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_func_curtime_local($3);
|
2003-08-11 21:44:43 +02:00
|
|
|
Lex->safe_to_cache_query=0;
|
2003-01-25 14:07:51 +01:00
|
|
|
}
|
2006-11-02 19:01:53 +01:00
|
|
|
| DATE_ADD_INTERVAL '(' expr ',' interval_expr interval ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_date_add_interval($3,$5,$6,0); }
|
|
|
|
| DATE_SUB_INTERVAL '(' expr ',' interval_expr interval ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_date_add_interval($3,$5,$6,1); }
|
|
|
|
| EXTRACT_SYM '(' interval FROM expr ')'
|
|
|
|
{ $$=new (YYTHD->mem_root) Item_extract( $3, $5); }
|
|
|
|
| GET_FORMAT '(' date_time_type ',' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_get_format($3, $5); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| NOW_SYM optional_braces
|
2006-11-02 19:01:53 +01:00
|
|
|
{
|
|
|
|
$$= new (YYTHD->mem_root) Item_func_now_local();
|
|
|
|
Lex->safe_to_cache_query=0;
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| NOW_SYM '(' expr ')'
|
2003-07-01 21:40:59 +02:00
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_func_now_local($3);
|
|
|
|
Lex->safe_to_cache_query=0;
|
|
|
|
}
|
2004-11-17 16:49:10 +01:00
|
|
|
| POSITION_SYM '(' bit_expr IN_SYM expr ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$ = new (YYTHD->mem_root) Item_func_locate($5,$3); }
|
2003-06-23 09:56:44 +02:00
|
|
|
| SUBDATE_SYM '(' expr ',' expr ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{
|
|
|
|
$$= new (YYTHD->mem_root) Item_date_add_interval($3, $5,
|
|
|
|
INTERVAL_DAY, 1);
|
|
|
|
}
|
2003-06-23 09:56:44 +02:00
|
|
|
| SUBDATE_SYM '(' expr ',' INTERVAL_SYM expr interval ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_date_add_interval($3, $6, $7, 1); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| SUBSTRING '(' expr ',' expr ',' expr ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_substr($3,$5,$7); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| SUBSTRING '(' expr ',' expr ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_substr($3,$5); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| SUBSTRING '(' expr FROM expr FOR_SYM expr ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_substr($3,$5,$7); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| SUBSTRING '(' expr FROM expr ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_substr($3,$5); }
|
2005-08-25 00:50:58 +02:00
|
|
|
| SYSDATE optional_braces
|
2006-03-10 15:47:56 +01:00
|
|
|
{
|
|
|
|
if (global_system_variables.sysdate_is_now == 0)
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_func_sysdate_local();
|
|
|
|
else
|
|
|
|
$$= new (YYTHD->mem_root) Item_func_now_local();
|
2006-03-10 15:47:56 +01:00
|
|
|
Lex->safe_to_cache_query=0;
|
|
|
|
}
|
2005-08-25 00:50:58 +02:00
|
|
|
| SYSDATE '(' expr ')'
|
2006-03-10 15:47:56 +01:00
|
|
|
{
|
|
|
|
if (global_system_variables.sysdate_is_now == 0)
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_func_sysdate_local($3);
|
|
|
|
else
|
|
|
|
$$= new (YYTHD->mem_root) Item_func_now_local($3);
|
2006-03-10 15:47:56 +01:00
|
|
|
Lex->safe_to_cache_query=0;
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
| TIMESTAMP_ADD '(' interval_time_st ',' expr ',' expr ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_date_add_interval($7,$5,$3,0); }
|
2004-11-12 04:01:46 +01:00
|
|
|
| TIMESTAMP_DIFF '(' interval_time_st ',' expr ',' expr ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_timestamp_diff($5,$7,$3); }
|
|
|
|
| UTC_DATE_SYM optional_braces
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
$$= new (YYTHD->mem_root) Item_func_curdate_utc();
|
|
|
|
Lex->safe_to_cache_query=0;
|
|
|
|
}
|
|
|
|
| UTC_TIME_SYM optional_braces
|
|
|
|
{
|
|
|
|
$$= new (YYTHD->mem_root) Item_func_curtime_utc();
|
|
|
|
Lex->safe_to_cache_query=0;
|
|
|
|
}
|
|
|
|
| UTC_TIMESTAMP_SYM optional_braces
|
|
|
|
{
|
|
|
|
$$= new (YYTHD->mem_root) Item_func_now_utc();
|
|
|
|
Lex->safe_to_cache_query=0;
|
|
|
|
}
|
|
|
|
;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2006-11-02 19:01:53 +01:00
|
|
|
/*
|
2006-12-05 00:31:30 +01:00
|
|
|
Functions calls using a non reserved keyword, and using a regular syntax.
|
2006-11-02 19:01:53 +01:00
|
|
|
Because the non reserved keyword is used in another part of the grammar,
|
|
|
|
a dedicated rule is needed here.
|
|
|
|
*/
|
|
|
|
function_call_conflict:
|
|
|
|
ASCII_SYM '(' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_ascii($3); }
|
|
|
|
| CHARSET '(' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_charset($3); }
|
|
|
|
| COALESCE '(' expr_list ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_coalesce(* $3); }
|
|
|
|
| COLLATION_SYM '(' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_collation($3); }
|
|
|
|
| DATABASE '(' ')'
|
|
|
|
{
|
|
|
|
$$= new (YYTHD->mem_root) Item_func_database();
|
|
|
|
Lex->safe_to_cache_query=0;
|
|
|
|
}
|
|
|
|
| IF '(' expr ',' expr ',' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_if($3,$5,$7); }
|
|
|
|
| MICROSECOND_SYM '(' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_microsecond($3); }
|
|
|
|
| MOD_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$ = new (YYTHD->mem_root) Item_func_mod( $3, $5); }
|
|
|
|
| OLD_PASSWORD '(' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_old_password($3); }
|
|
|
|
| PASSWORD '(' expr ')'
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
Item* i1;
|
|
|
|
if (thd->variables.old_passwords)
|
|
|
|
i1= new (thd->mem_root) Item_func_old_password($3);
|
|
|
|
else
|
|
|
|
i1= new (thd->mem_root) Item_func_password($3);
|
|
|
|
$$= i1;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2006-11-02 19:01:53 +01:00
|
|
|
| QUARTER_SYM '(' expr ')'
|
|
|
|
{ $$ = new (YYTHD->mem_root) Item_func_quarter($3); }
|
|
|
|
| REPEAT_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_repeat($3,$5); }
|
|
|
|
| REPLACE '(' expr ',' expr ',' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_replace($3,$5,$7); }
|
|
|
|
| TRUNCATE_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_round($3,$5,1); }
|
|
|
|
| WEEK_SYM '(' expr ')'
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
Item *i1= new (thd->mem_root) Item_int((char*) "0",
|
|
|
|
thd->variables.default_week_format,
|
|
|
|
1);
|
|
|
|
|
|
|
|
$$= new (thd->mem_root) Item_func_week($3, i1);
|
|
|
|
}
|
|
|
|
| WEEK_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_week($3,$5); }
|
|
|
|
| geometry_function
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
#ifdef HAVE_SPATIAL
|
|
|
|
$$= $1;
|
|
|
|
#else
|
|
|
|
my_error(ER_FEATURE_DISABLED, MYF(0),
|
|
|
|
sym_group_geom.name, sym_group_geom.needed_define);
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-11-02 19:01:53 +01:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
geometry_function:
|
|
|
|
CONTAINS_SYM '(' expr ',' expr ')'
|
|
|
|
{
|
|
|
|
$$= GEOM_NEW(YYTHD,
|
|
|
|
Item_func_spatial_rel($3, $5,
|
|
|
|
Item_func::SP_CONTAINS_FUNC));
|
|
|
|
}
|
|
|
|
| GEOMETRYCOLLECTION '(' expr_list ')'
|
|
|
|
{
|
|
|
|
$$= GEOM_NEW(YYTHD,
|
|
|
|
Item_func_spatial_collection(* $3,
|
|
|
|
Geometry::wkb_geometrycollection,
|
|
|
|
Geometry::wkb_point));
|
|
|
|
}
|
|
|
|
| LINESTRING '(' expr_list ')'
|
|
|
|
{
|
|
|
|
$$= GEOM_NEW(YYTHD,
|
|
|
|
Item_func_spatial_collection(* $3,
|
|
|
|
Geometry::wkb_linestring,
|
|
|
|
Geometry::wkb_point));
|
|
|
|
}
|
|
|
|
| MULTILINESTRING '(' expr_list ')'
|
|
|
|
{
|
|
|
|
$$= GEOM_NEW(YYTHD,
|
|
|
|
Item_func_spatial_collection(* $3,
|
|
|
|
Geometry::wkb_multilinestring,
|
|
|
|
Geometry::wkb_linestring));
|
|
|
|
}
|
|
|
|
| MULTIPOINT '(' expr_list ')'
|
|
|
|
{
|
|
|
|
$$= GEOM_NEW(YYTHD,
|
|
|
|
Item_func_spatial_collection(* $3,
|
|
|
|
Geometry::wkb_multipoint,
|
|
|
|
Geometry::wkb_point));
|
|
|
|
}
|
|
|
|
| MULTIPOLYGON '(' expr_list ')'
|
|
|
|
{
|
|
|
|
$$= GEOM_NEW(YYTHD,
|
|
|
|
Item_func_spatial_collection(* $3,
|
|
|
|
Geometry::wkb_multipolygon,
|
|
|
|
Geometry::wkb_polygon));
|
|
|
|
}
|
|
|
|
| POINT_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$= GEOM_NEW(YYTHD, Item_func_point($3,$5)); }
|
|
|
|
| POLYGON '(' expr_list ')'
|
|
|
|
{
|
|
|
|
$$= GEOM_NEW(YYTHD,
|
|
|
|
Item_func_spatial_collection(* $3,
|
|
|
|
Geometry::wkb_polygon,
|
|
|
|
Geometry::wkb_linestring));
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
/*
|
|
|
|
Regular function calls.
|
|
|
|
The function name is *not* a token, and therefore is guaranteed to not
|
|
|
|
introduce side effects to the language in general.
|
|
|
|
MAINTAINER:
|
|
|
|
All the new functions implemented for new features should fit into
|
|
|
|
this category. The place to implement the function itself is
|
|
|
|
in sql/item_create.cc
|
|
|
|
*/
|
|
|
|
function_call_generic:
|
|
|
|
IDENT_sys '('
|
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
#ifdef HAVE_DLOPEN
|
2006-11-02 19:01:53 +01:00
|
|
|
udf_func *udf= 0;
|
2006-11-17 16:01:35 +01:00
|
|
|
LEX *lex= Lex;
|
2006-11-02 19:01:53 +01:00
|
|
|
if (using_udf_functions &&
|
|
|
|
(udf= find_udf($1.str, $1.length)) &&
|
|
|
|
udf->type == UDFTYPE_AGGREGATE)
|
|
|
|
{
|
|
|
|
if (lex->current_select->inc_in_sum_expr())
|
2005-09-20 11:28:23 +02:00
|
|
|
{
|
2007-03-07 14:08:36 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-09-20 11:28:23 +02:00
|
|
|
}
|
2006-11-02 19:01:53 +01:00
|
|
|
}
|
|
|
|
/* Temporary placing the result of find_udf in $3 */
|
2006-12-04 19:38:40 +01:00
|
|
|
$<udf>$= udf;
|
2005-09-20 11:28:23 +02:00
|
|
|
#endif
|
2006-11-02 19:01:53 +01:00
|
|
|
}
|
2006-11-20 11:46:47 +01:00
|
|
|
udf_expr_list ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
Create_func *builder;
|
|
|
|
Item *item= NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
Implementation note:
|
|
|
|
names are resolved with the following order:
|
|
|
|
- MySQL native functions,
|
|
|
|
- User Defined Functions,
|
|
|
|
- Stored Functions (assuming the current <use> database)
|
|
|
|
|
|
|
|
This will be revised with WL#2128 (SQL PATH)
|
|
|
|
*/
|
|
|
|
builder= find_native_function_builder(thd, $1);
|
|
|
|
if (builder)
|
|
|
|
{
|
|
|
|
item= builder->create(thd, $1, $4);
|
2005-09-20 11:28:23 +02:00
|
|
|
}
|
2006-11-02 19:01:53 +01:00
|
|
|
else
|
2005-09-20 11:28:23 +02:00
|
|
|
{
|
|
|
|
#ifdef HAVE_DLOPEN
|
2006-11-02 19:01:53 +01:00
|
|
|
/* Retrieving the result of find_udf */
|
2006-12-04 19:38:40 +01:00
|
|
|
udf_func *udf= $<udf>3;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2006-12-04 19:38:40 +01:00
|
|
|
if (udf)
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2005-09-20 11:28:23 +02:00
|
|
|
if (udf->type == UDFTYPE_AGGREGATE)
|
2006-11-02 19:01:53 +01:00
|
|
|
{
|
2005-09-20 11:28:23 +02:00
|
|
|
Select->in_sum_expr--;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2006-11-02 19:01:53 +01:00
|
|
|
|
|
|
|
item= Create_udf_func::s_singleton.create(thd, udf, $4);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
else
|
2006-11-02 19:01:53 +01:00
|
|
|
#endif
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2006-11-02 19:01:53 +01:00
|
|
|
builder= find_qualified_function_builder(thd);
|
|
|
|
DBUG_ASSERT(builder);
|
|
|
|
item= builder->create(thd, $1, $4);
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2006-11-02 19:01:53 +01:00
|
|
|
|
|
|
|
if (! ($$= item))
|
|
|
|
{
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-02-19 13:05:35 +01:00
|
|
|
}
|
2006-11-02 19:01:53 +01:00
|
|
|
}
|
2006-11-20 11:46:47 +01:00
|
|
|
| ident '.' ident '(' opt_expr_list ')'
|
2006-11-02 19:01:53 +01:00
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
Create_qfunc *builder;
|
|
|
|
Item *item= NULL;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2006-11-02 19:01:53 +01:00
|
|
|
/*
|
|
|
|
The following in practice calls:
|
|
|
|
<code>Create_sp_func::create()</code>
|
|
|
|
and builds a stored function.
|
|
|
|
|
|
|
|
However, it's important to maintain the interface between the
|
|
|
|
parser and the implementation in item_create.cc clean,
|
|
|
|
since this will change with WL#2128 (SQL PATH):
|
|
|
|
- INFORMATION_SCHEMA.version() is the SQL 99 syntax for the native
|
2006-12-05 00:31:30 +01:00
|
|
|
function version(),
|
2006-11-02 19:01:53 +01:00
|
|
|
- MySQL.version() is the SQL 2003 syntax for the native function
|
|
|
|
version() (a vendor can specify any schema).
|
|
|
|
*/
|
|
|
|
|
|
|
|
builder= find_qualified_function_builder(thd);
|
|
|
|
DBUG_ASSERT(builder);
|
2007-03-29 17:12:12 +02:00
|
|
|
item= builder->create(thd, $1, $3, true, $5);
|
2006-11-02 19:01:53 +01:00
|
|
|
|
|
|
|
if (! ($$= item))
|
|
|
|
{
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-11-02 19:01:53 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
;
|
2004-01-15 18:06:22 +01:00
|
|
|
|
2003-10-22 17:57:09 +02:00
|
|
|
fulltext_options:
|
2006-02-14 13:19:54 +01:00
|
|
|
opt_natural_language_mode opt_query_expansion
|
|
|
|
{ $$= $1 | $2; }
|
|
|
|
| IN_SYM BOOLEAN_SYM MODE_SYM
|
|
|
|
{ $$= FT_BOOL; }
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_natural_language_mode:
|
|
|
|
/* nothing */ { $$= FT_NL; }
|
|
|
|
| IN_SYM NATURAL LANGUAGE_SYM MODE_SYM { $$= FT_NL; }
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_query_expansion:
|
|
|
|
/* nothing */ { $$= 0; }
|
|
|
|
| WITH QUERY_SYM EXPANSION_SYM { $$= FT_EXPAND; }
|
2003-10-22 17:57:09 +02:00
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
udf_expr_list:
|
2004-11-12 04:01:46 +01:00
|
|
|
/* empty */ { $$= NULL; }
|
|
|
|
| udf_expr_list2 { $$= $1;}
|
|
|
|
;
|
|
|
|
|
|
|
|
udf_expr_list2:
|
|
|
|
{ Select->expr_list.push_front(new List<Item>); }
|
|
|
|
udf_expr_list3
|
|
|
|
{ $$= Select->expr_list.pop(); }
|
|
|
|
;
|
|
|
|
|
|
|
|
udf_expr_list3:
|
|
|
|
udf_expr
|
|
|
|
{
|
|
|
|
Select->expr_list.head()->push_back($1);
|
|
|
|
}
|
|
|
|
| udf_expr_list3 ',' udf_expr
|
|
|
|
{
|
|
|
|
Select->expr_list.head()->push_back($3);
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
udf_expr:
|
|
|
|
remember_name expr remember_end select_alias
|
|
|
|
{
|
2006-10-24 14:26:41 +02:00
|
|
|
/*
|
|
|
|
Use Item::name as a storage for the attribute value of user
|
|
|
|
defined function argument. It is safe to use Item::name
|
|
|
|
because the syntax will not allow having an explicit name here.
|
|
|
|
See WL#1017 re. udf attributes.
|
|
|
|
*/
|
2004-11-12 04:01:46 +01:00
|
|
|
if ($4.str)
|
2005-06-21 19:30:48 +02:00
|
|
|
{
|
|
|
|
$2->is_autogenerated_name= FALSE;
|
2006-07-15 22:45:38 +02:00
|
|
|
$2->set_name($4.str, $4.length, system_charset_info);
|
2005-06-21 19:30:48 +02:00
|
|
|
}
|
2006-12-04 19:38:40 +01:00
|
|
|
else
|
2005-06-21 19:30:48 +02:00
|
|
|
$2->set_name($1, (uint) ($3 - $1), YYTHD->charset());
|
2004-11-12 04:01:46 +01:00
|
|
|
$$= $2;
|
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
sum_expr:
|
|
|
|
AVG_SYM '(' in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_avg($3); }
|
2005-03-13 21:50:43 +01:00
|
|
|
| AVG_SYM '(' DISTINCT in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_avg_distinct($4); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| BIT_AND '(' in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_and($3); }
|
|
|
|
| BIT_OR '(' in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_or($3); }
|
2003-10-15 08:11:03 +02:00
|
|
|
| BIT_XOR '(' in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_xor($3); }
|
2003-02-06 15:55:59 +01:00
|
|
|
| COUNT_SYM '(' opt_all '*' ')'
|
2000-07-31 21:29:14 +02:00
|
|
|
{ $$=new Item_sum_count(new Item_int((int32) 0L,1)); }
|
|
|
|
| COUNT_SYM '(' in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_count($3); }
|
2003-05-13 09:54:07 +02:00
|
|
|
| COUNT_SYM '(' DISTINCT
|
2003-07-03 01:30:52 +02:00
|
|
|
{ Select->in_sum_expr++; }
|
2003-05-13 09:54:07 +02:00
|
|
|
expr_list
|
2003-07-03 01:30:52 +02:00
|
|
|
{ Select->in_sum_expr--; }
|
2003-05-13 09:54:07 +02:00
|
|
|
')'
|
|
|
|
{ $$=new Item_sum_count_distinct(* $5); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| MIN_SYM '(' in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_min($3); }
|
2004-11-12 04:01:46 +01:00
|
|
|
/*
|
|
|
|
According to ANSI SQL, DISTINCT is allowed and has
|
2006-12-05 00:31:30 +01:00
|
|
|
no sense inside MIN and MAX grouping functions; so MIN|MAX(DISTINCT ...)
|
2004-11-12 04:01:46 +01:00
|
|
|
is processed like an ordinary MIN | MAX()
|
|
|
|
*/
|
|
|
|
| MIN_SYM '(' DISTINCT in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_min($4); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| MAX_SYM '(' in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_max($3); }
|
2004-11-12 04:01:46 +01:00
|
|
|
| MAX_SYM '(' DISTINCT in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_max($4); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| STD_SYM '(' in_sum_expr ')'
|
2005-02-25 19:19:04 +01:00
|
|
|
{ $$=new Item_sum_std($3, 0); }
|
2002-12-14 00:36:59 +01:00
|
|
|
| VARIANCE_SYM '(' in_sum_expr ')'
|
2005-02-25 19:19:04 +01:00
|
|
|
{ $$=new Item_sum_variance($3, 0); }
|
|
|
|
| STDDEV_SAMP_SYM '(' in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_std($3, 1); }
|
|
|
|
| VAR_SAMP_SYM '(' in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_variance($3, 1); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| SUM_SYM '(' in_sum_expr ')'
|
2003-03-18 00:07:40 +01:00
|
|
|
{ $$=new Item_sum_sum($3); }
|
2004-11-12 04:01:46 +01:00
|
|
|
| SUM_SYM '(' DISTINCT in_sum_expr ')'
|
|
|
|
{ $$=new Item_sum_sum_distinct($4); }
|
2004-04-07 03:33:58 +02:00
|
|
|
| GROUP_CONCAT_SYM '(' opt_distinct
|
|
|
|
{ Select->in_sum_expr++; }
|
|
|
|
expr_list opt_gorder_clause
|
|
|
|
opt_gconcat_separator
|
|
|
|
')'
|
2003-08-11 21:44:43 +02:00
|
|
|
{
|
2005-07-01 06:05:42 +02:00
|
|
|
SELECT_LEX *sel= Select;
|
|
|
|
sel->in_sum_expr--;
|
2005-08-12 16:57:19 +02:00
|
|
|
$$=new Item_func_group_concat(Lex->current_context(), $3, $5,
|
2005-07-01 06:05:42 +02:00
|
|
|
sel->gorder_list, $7);
|
2004-04-07 03:33:58 +02:00
|
|
|
$5->empty();
|
2003-03-18 00:07:40 +01:00
|
|
|
};
|
|
|
|
|
2006-10-12 16:02:57 +02:00
|
|
|
variable:
|
|
|
|
'@'
|
|
|
|
{
|
|
|
|
if (! Lex->parsing_options.allows_variable)
|
|
|
|
{
|
|
|
|
my_error(ER_VIEW_SELECT_VARIABLE, MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-10-12 16:02:57 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
variable_aux
|
|
|
|
{
|
|
|
|
$$= $3;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
variable_aux:
|
|
|
|
ident_or_text SET_VAR expr
|
|
|
|
{
|
|
|
|
$$= new Item_func_set_user_var($1, $3);
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->uncacheable(UNCACHEABLE_RAND);
|
|
|
|
}
|
|
|
|
| ident_or_text
|
|
|
|
{
|
|
|
|
$$= new Item_func_get_user_var($1);
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->uncacheable(UNCACHEABLE_RAND);
|
|
|
|
}
|
|
|
|
| '@' opt_var_ident_type ident_or_text opt_component
|
|
|
|
{
|
|
|
|
if ($3.str && $4.str && check_reserved_words(&$3))
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2006-10-12 16:02:57 +02:00
|
|
|
}
|
|
|
|
if (!($$= get_system_var(YYTHD, $2, $3, $4)))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-10-12 16:02:57 +02:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2003-03-18 00:07:40 +01:00
|
|
|
opt_distinct:
|
|
|
|
/* empty */ { $$ = 0; }
|
|
|
|
|DISTINCT { $$ = 1; };
|
|
|
|
|
|
|
|
opt_gconcat_separator:
|
2007-06-22 14:18:40 +02:00
|
|
|
/* empty */
|
|
|
|
{
|
|
|
|
$$= new (YYTHD->mem_root) String(",", 1, &my_charset_latin1);
|
|
|
|
}
|
|
|
|
| SEPARATOR_SYM text_string { $$ = $2; };
|
2003-08-11 21:44:43 +02:00
|
|
|
|
2003-03-18 00:07:40 +01:00
|
|
|
|
|
|
|
opt_gorder_clause:
|
2003-10-12 16:56:05 +02:00
|
|
|
/* empty */
|
|
|
|
{
|
2004-04-05 12:56:05 +02:00
|
|
|
Select->gorder_list = NULL;
|
2003-10-12 16:56:05 +02:00
|
|
|
}
|
|
|
|
| order_clause
|
|
|
|
{
|
2004-04-05 12:56:05 +02:00
|
|
|
SELECT_LEX *select= Select;
|
|
|
|
select->gorder_list=
|
|
|
|
(SQL_LIST*) sql_memdup((char*) &select->order_list,
|
2003-10-12 16:56:05 +02:00
|
|
|
sizeof(st_sql_list));
|
2004-04-05 12:56:05 +02:00
|
|
|
select->order_list.empty();
|
2003-10-12 16:56:05 +02:00
|
|
|
};
|
2003-08-11 21:44:43 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
in_sum_expr:
|
2003-02-06 15:55:59 +01:00
|
|
|
opt_all
|
2002-10-30 12:18:52 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
if (lex->current_select->inc_in_sum_expr())
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2002-10-30 12:18:52 +01:00
|
|
|
}
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
expr
|
|
|
|
{
|
2003-07-03 01:30:52 +02:00
|
|
|
Select->in_sum_expr--;
|
2003-02-07 15:38:37 +01:00
|
|
|
$$= $3;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2004-01-22 21:13:24 +01:00
|
|
|
cast_type:
|
2005-02-08 23:50:45 +01:00
|
|
|
BINARY opt_len { $$=ITEM_CAST_CHAR; Lex->charset= &my_charset_bin; Lex->dec= 0; }
|
|
|
|
| CHAR_SYM opt_len opt_binary { $$=ITEM_CAST_CHAR; Lex->dec= 0; }
|
2005-02-09 13:32:43 +01:00
|
|
|
| NCHAR_SYM opt_len { $$=ITEM_CAST_CHAR; Lex->charset= national_charset_info; Lex->dec=0; }
|
2005-02-08 23:50:45 +01:00
|
|
|
| SIGNED_SYM { $$=ITEM_CAST_SIGNED_INT; Lex->charset= NULL; Lex->dec=Lex->length= (char*)0; }
|
|
|
|
| SIGNED_SYM INT_SYM { $$=ITEM_CAST_SIGNED_INT; Lex->charset= NULL; Lex->dec=Lex->length= (char*)0; }
|
|
|
|
| UNSIGNED { $$=ITEM_CAST_UNSIGNED_INT; Lex->charset= NULL; Lex->dec=Lex->length= (char*)0; }
|
|
|
|
| UNSIGNED INT_SYM { $$=ITEM_CAST_UNSIGNED_INT; Lex->charset= NULL; Lex->dec=Lex->length= (char*)0; }
|
|
|
|
| DATE_SYM { $$=ITEM_CAST_DATE; Lex->charset= NULL; Lex->dec=Lex->length= (char*)0; }
|
|
|
|
| TIME_SYM { $$=ITEM_CAST_TIME; Lex->charset= NULL; Lex->dec=Lex->length= (char*)0; }
|
|
|
|
| DATETIME { $$=ITEM_CAST_DATETIME; Lex->charset= NULL; Lex->dec=Lex->length= (char*)0; }
|
|
|
|
| DECIMAL_SYM float_options { $$=ITEM_CAST_DECIMAL; Lex->charset= NULL; }
|
2003-08-21 11:15:25 +02:00
|
|
|
;
|
|
|
|
|
2006-10-24 14:26:41 +02:00
|
|
|
opt_expr_list:
|
|
|
|
/* empty */ { $$= NULL; }
|
|
|
|
| expr_list { $$= $1;}
|
|
|
|
;
|
2006-11-02 19:01:53 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
expr_list:
|
2001-06-03 16:07:26 +02:00
|
|
|
{ Select->expr_list.push_front(new List<Item>); }
|
2000-07-31 21:29:14 +02:00
|
|
|
expr_list2
|
2002-04-16 01:09:30 +02:00
|
|
|
{ $$= Select->expr_list.pop(); };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
expr_list2:
|
2001-06-03 16:07:26 +02:00
|
|
|
expr { Select->expr_list.head()->push_back($1); }
|
2002-04-16 01:09:30 +02:00
|
|
|
| expr_list2 ',' expr { Select->expr_list.head()->push_back($3); };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-10-09 14:53:54 +02:00
|
|
|
ident_list_arg:
|
|
|
|
ident_list { $$= $1; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| '(' ident_list ')' { $$= $2; };
|
2001-10-09 14:53:54 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
ident_list:
|
2001-06-03 16:07:26 +02:00
|
|
|
{ Select->expr_list.push_front(new List<Item>); }
|
2000-07-31 21:29:14 +02:00
|
|
|
ident_list2
|
2002-04-16 01:09:30 +02:00
|
|
|
{ $$= Select->expr_list.pop(); };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
ident_list2:
|
2001-06-03 16:07:26 +02:00
|
|
|
simple_ident { Select->expr_list.head()->push_back($1); }
|
2002-04-16 01:09:30 +02:00
|
|
|
| ident_list2 ',' simple_ident { Select->expr_list.head()->push_back($3); };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_expr:
|
|
|
|
/* empty */ { $$= NULL; }
|
2003-10-20 15:53:48 +02:00
|
|
|
| expr { $$= $1; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_else:
|
|
|
|
/* empty */ { $$= NULL; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| ELSE expr { $$= $2; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
when_list:
|
Bug#19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation)
Note to the reviewer
====================
Warning: reviewing this patch is somewhat involved.
Due to the nature of several issues all affecting the same area,
fixing separately each issue is not practical, since each fix can not be
implemented and tested independently.
In particular, the issues with
- rule recursion
- nested case statements
- forward jump resolution (backpatch list)
are tightly coupled (see below).
Definitions
===========
The expression
CASE expr
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Simple Case Expression".
The expression
CASE
WHEN expr THEN expr
WHEN expr THEN expr
...
END
is a "Searched Case Expression".
The statement
CASE expr
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Simple Case Statement".
The statement
CASE
WHEN expr THEN stmts
WHEN expr THEN stmts
...
END CASE
is a "Searched Case Statement".
A "Left Recursive" rule is like
list:
element
| list element
;
A "Right Recursive" rule is like
list:
element
| element list
;
Left and right recursion produces the same language, the difference only
affects the *order* in which the text is parsed.
In a descendant parser (usually written manually), right recursion works
very well, and is typically implemented with a while loop.
In an ascendant parser (yacc/bison) left recursion works very well,
and is implemented naturally by the parser stack.
In both cases, using the wrong type or recursion is very bad and should be
avoided, as it causes technical issues with the parser implementation.
Before this change
==================
The "Simple Case Expression" and "Searched Case Expression" were both
implemented by the "when_list" and "when_list2" rules, which are left
recursive (ok).
These rules, however, used lex->when_list instead of using the parser stack,
which is more complex that necessary, and potentially dangerous because
of other rules using THD::reset_lex.
The "Simple Case Statement" and "Searched Case Statements" were implemented
by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
Both cases were right recursive (bad).
The grammar involved was convoluted, and is assumed to be the results of
tweaks to get the code generation to work, but is not what someone would
naturally write.
In addition, using a common rule for both "Simple" and "Searched" case
statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
which is a flag and not a stack, and therefore does not take into account
*nested* case statements. This leads to incorrect generated code, and either
a server crash or an incorrect result.
With regards to the backpatch mechanism, a *different* backpatch list was
created for each jump from "WHEN expr THEN stmt" to "END CASE", which
relied on the grammar to be right recursive.
This is a mis-use of the backpatch list, since this list can resolve
multiple references to the same target at once.
The optimizer algorithm used to detect dead code in the "assembly" SQL
instructions, implemented by sp_head::opt_mark(uint ip), was recursive
in some cases (a conditional jump pointing forward to another conditional
jump).
In case of specially crafted code, like
- a long list of "IF expr THEN stmt END IF"
- a long CASE statement
this would actually cause a server crash with a stack overflow.
In general, having a stack that grows proportionally with user data (the
SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
In debug builds only, creating a SP / SF / Trigger which had a significant
amount of code would spend --literally-- several minutes in sp_head::create,
because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
There are several issues with this code:
- in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
which create a sting representation of the code which is 500 000 bytes
long,
- using a String instead of an io stream causes performances to degrade
to a total server freeze, as time is spent doing realloc of a buffer
always too short,
- Printing a 500 000 long string in the debug log is too verbose,
- Generating this string even when DBUG_PRINT is off is useless,
- Having code that potentially can affect the server behavior, used with
#ifdef / #endif is useful in some cases, but is also a bad practice.
After this change
=================
"Case Expressions" (both simple and searched) have been simplified to
not use LEX::when_list, which has been removed.
Considering all the issues affecting case statements, the grammar for these
has been totally re written.
The existing actions, used to generate "assembly" sp_inst* code, have been
preserved but moved in the new grammar, with the following changes:
a) Bison rules are no longer shared between "Simple" and "Searched" case
statements, because a stack instead of a flag is required to handle them.
Nested statements are handled naturally by the parser stack, which by
definition uses the correct rule in the correct context.
Nested statements of the opposite type (simple vs searched) works correctly.
The flag sp_head::IN_SIMPLE_CASE is no longer used.
This is a step towards resolution of WL#2999, which correctly identified
that temporary parsing flags do not belong to sp_head.
The code in the action is shared by mean of the case_stmt_action_xxx()
helpers.
b) The backpatch mechanism, used to resolve forward jumps in the generated
code, has been changed to:
- create a label for the instruction following 'END CASE',
- register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
backpatch list associated with the 'END CASE' label
- resolve all the forward jumps for this label at once.
In addition, the code involving backpatch has been commented, so that a
reader can now understand by reading matching "Registering" and "Resolving"
comments how the forward jumps are resolved and what target they resolve to,
as this is far from evident when reading the code alone.
The implementation of sp_head::opt_mark() has been revised to avoid
recursive calls from jump instructions, and instead add the jump location
to the list of paths to explore during the flow analysis of the instruction
graph, with a call to sp_head::add_mark_lead().
In addition, the flow analysis will stop if an instruction has already
been marked as reachable, which the previous code failed to do in the
recursive case.
sp_head::opt_mark() is now private, to prevent new calls to this method from
being introduced.
The debug code present in sp_head::create() has been removed.
Considering that SHOW PROCEDURE CODE is also available in debug builds,
and can be used anytime regardless of the trace level, as opposed to
"CREATE PROCEDURE" time and only if the trace was on,
removing the code actually makes debugging easier (usable trace).
Tests have been written to cover the parser overflow (big CASE),
and to cover nested CASE statements.
2006-11-17 20:14:29 +01:00
|
|
|
WHEN_SYM expr THEN_SYM expr
|
|
|
|
{
|
|
|
|
$$= new List<Item>;
|
|
|
|
$$->push_back($2);
|
|
|
|
$$->push_back($4);
|
|
|
|
}
|
|
|
|
| when_list WHEN_SYM expr THEN_SYM expr
|
|
|
|
{
|
|
|
|
$1->push_back($3);
|
|
|
|
$1->push_back($5);
|
|
|
|
$$= $1;
|
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-03-16 01:13:23 +01:00
|
|
|
/* Warning - may return NULL in case of incomplete SELECT */
|
2004-11-12 04:01:46 +01:00
|
|
|
table_ref:
|
|
|
|
table_factor { $$=$1; }
|
Bug#21462 (Stored procedures with no arguments require parenthesis)
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.
2006-10-09 18:59:02 +02:00
|
|
|
| join_table
|
2004-09-14 18:28:29 +02:00
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
if (!($$= lex->current_select->nest_last_join(lex->thd)))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-09-14 18:28:29 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
join_table_list:
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
derived_table_list { MYSQL_YYABORT_UNLESS($$=$1); }
|
2005-03-16 01:13:23 +01:00
|
|
|
;
|
2005-04-04 00:50:05 +02:00
|
|
|
|
2005-03-16 01:13:23 +01:00
|
|
|
/* Warning - may return NULL in case of incomplete SELECT */
|
|
|
|
derived_table_list:
|
2004-11-12 04:01:46 +01:00
|
|
|
table_ref { $$=$1; }
|
2005-03-16 01:13:23 +01:00
|
|
|
| derived_table_list ',' table_ref
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1 && ($$=$3));
|
2005-03-16 01:13:23 +01:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
|
|
|
|
2005-10-25 08:00:57 +02:00
|
|
|
/*
|
|
|
|
Notice that JOIN is a left-associative operation, and it must be parsed
|
|
|
|
as such, that is, the parser must process first the left join operand
|
|
|
|
then the right one. Such order of processing ensures that the parser
|
|
|
|
produces correct join trees which is essential for semantic analysis
|
|
|
|
and subsequent optimization phases.
|
|
|
|
*/
|
2004-11-12 04:01:46 +01:00
|
|
|
join_table:
|
2005-10-25 08:00:57 +02:00
|
|
|
/* INNER JOIN variants */
|
2005-09-10 14:01:54 +02:00
|
|
|
/*
|
2005-10-25 08:00:57 +02:00
|
|
|
Use %prec to evaluate production 'table_ref' before 'normal_join'
|
|
|
|
so that [INNER | CROSS] JOIN is properly nested as other
|
|
|
|
left-associative joins.
|
2005-09-10 14:01:54 +02:00
|
|
|
*/
|
|
|
|
table_ref %prec TABLE_REF_PRIORITY normal_join table_ref
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
{ MYSQL_YYABORT_UNLESS($1 && ($$=$3)); }
|
2004-11-12 04:01:46 +01:00
|
|
|
| table_ref STRAIGHT_JOIN table_factor
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
{ MYSQL_YYABORT_UNLESS($1 && ($$=$3)); $3->straight=1; }
|
2005-08-12 16:57:19 +02:00
|
|
|
| table_ref normal_join table_ref
|
|
|
|
ON
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1 && $3);
|
2005-08-12 16:57:19 +02:00
|
|
|
/* Change the current name resolution context to a local context. */
|
2005-11-28 20:57:50 +01:00
|
|
|
if (push_new_name_resolution_context(YYTHD, $1, $3))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-09-25 15:15:14 +02:00
|
|
|
Select->parsing_place= IN_ON;
|
2005-08-12 16:57:19 +02:00
|
|
|
}
|
|
|
|
expr
|
|
|
|
{
|
|
|
|
add_join_on($3,$6);
|
|
|
|
Lex->pop_context();
|
2006-09-25 15:15:14 +02:00
|
|
|
Select->parsing_place= NO_MATTER;
|
2005-08-12 16:57:19 +02:00
|
|
|
}
|
|
|
|
| table_ref STRAIGHT_JOIN table_factor
|
|
|
|
ON
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1 && $3);
|
2005-08-12 16:57:19 +02:00
|
|
|
/* Change the current name resolution context to a local context. */
|
2005-11-28 20:57:50 +01:00
|
|
|
if (push_new_name_resolution_context(YYTHD, $1, $3))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-09-25 15:15:14 +02:00
|
|
|
Select->parsing_place= IN_ON;
|
2005-08-12 16:57:19 +02:00
|
|
|
}
|
|
|
|
expr
|
|
|
|
{
|
|
|
|
$3->straight=1;
|
|
|
|
add_join_on($3,$6);
|
|
|
|
Lex->pop_context();
|
2006-09-25 15:15:14 +02:00
|
|
|
Select->parsing_place= NO_MATTER;
|
2005-08-12 16:57:19 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
| table_ref normal_join table_ref
|
2003-08-11 21:44:43 +02:00
|
|
|
USING
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1 && $3);
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2003-02-06 15:55:59 +01:00
|
|
|
'(' using_list ')'
|
2007-01-31 15:04:38 +01:00
|
|
|
{ add_join_natural($1,$3,$7,Select); $$=$3; }
|
2005-10-25 08:00:57 +02:00
|
|
|
| table_ref NATURAL JOIN_SYM table_factor
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1 && ($$=$4));
|
2007-01-31 15:04:38 +01:00
|
|
|
add_join_natural($1,$4,NULL,Select);
|
2005-10-25 08:00:57 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* LEFT JOIN variants */
|
2005-08-12 16:57:19 +02:00
|
|
|
| table_ref LEFT opt_outer JOIN_SYM table_ref
|
|
|
|
ON
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1 && $5);
|
2005-08-12 16:57:19 +02:00
|
|
|
/* Change the current name resolution context to a local context. */
|
2005-11-28 20:57:50 +01:00
|
|
|
if (push_new_name_resolution_context(YYTHD, $1, $5))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-09-25 15:15:14 +02:00
|
|
|
Select->parsing_place= IN_ON;
|
2005-08-12 16:57:19 +02:00
|
|
|
}
|
|
|
|
expr
|
|
|
|
{
|
|
|
|
add_join_on($5,$8);
|
|
|
|
Lex->pop_context();
|
|
|
|
$5->outer_join|=JOIN_TYPE_LEFT;
|
|
|
|
$$=$5;
|
2006-09-25 15:15:14 +02:00
|
|
|
Select->parsing_place= NO_MATTER;
|
2005-08-12 16:57:19 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
| table_ref LEFT opt_outer JOIN_SYM table_factor
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1 && $5);
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
USING '(' using_list ')'
|
2007-01-31 15:04:38 +01:00
|
|
|
{
|
|
|
|
add_join_natural($1,$5,$9,Select);
|
|
|
|
$5->outer_join|=JOIN_TYPE_LEFT;
|
|
|
|
$$=$5;
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
| table_ref NATURAL LEFT opt_outer JOIN_SYM table_factor
|
2003-04-26 19:43:28 +02:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1 && $6);
|
2007-01-31 15:04:38 +01:00
|
|
|
add_join_natural($1,$6,NULL,Select);
|
2004-11-12 04:01:46 +01:00
|
|
|
$6->outer_join|=JOIN_TYPE_LEFT;
|
2003-04-26 19:43:28 +02:00
|
|
|
$$=$6;
|
|
|
|
}
|
2005-10-25 08:00:57 +02:00
|
|
|
|
|
|
|
/* RIGHT JOIN variants */
|
2005-08-12 16:57:19 +02:00
|
|
|
| table_ref RIGHT opt_outer JOIN_SYM table_ref
|
|
|
|
ON
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1 && $5);
|
2005-08-12 16:57:19 +02:00
|
|
|
/* Change the current name resolution context to a local context. */
|
2005-11-28 20:57:50 +01:00
|
|
|
if (push_new_name_resolution_context(YYTHD, $1, $5))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-09-25 15:15:14 +02:00
|
|
|
Select->parsing_place= IN_ON;
|
2005-08-12 16:57:19 +02:00
|
|
|
}
|
|
|
|
expr
|
2005-04-04 00:50:05 +02:00
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
if (!($$= lex->current_select->convert_right_join()))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-08-12 16:57:19 +02:00
|
|
|
add_join_on($$, $8);
|
|
|
|
Lex->pop_context();
|
2006-09-25 15:15:14 +02:00
|
|
|
Select->parsing_place= NO_MATTER;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
| table_ref RIGHT opt_outer JOIN_SYM table_factor
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1 && $5);
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2000-09-25 23:33:25 +02:00
|
|
|
USING '(' using_list ')'
|
2005-04-04 00:50:05 +02:00
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
if (!($$= lex->current_select->convert_right_join()))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2007-01-31 15:04:38 +01:00
|
|
|
add_join_natural($$,$5,$9,Select);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
| table_ref NATURAL RIGHT opt_outer JOIN_SYM table_factor
|
2003-04-26 19:43:28 +02:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1 && $6);
|
2007-01-31 15:04:38 +01:00
|
|
|
add_join_natural($6,$1,NULL,Select);
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
if (!($$= lex->current_select->convert_right_join()))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-10-25 08:00:57 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
normal_join:
|
2003-02-06 15:55:59 +01:00
|
|
|
JOIN_SYM {}
|
|
|
|
| INNER_SYM JOIN_SYM {}
|
|
|
|
| CROSS JOIN_SYM {}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-03-16 01:13:23 +01:00
|
|
|
/* Warning - may return NULL in case of incomplete SELECT */
|
2004-11-12 04:01:46 +01:00
|
|
|
table_factor:
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel= Select;
|
2003-01-09 21:42:31 +01:00
|
|
|
sel->table_join_options= 0;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
table_ident opt_table_alias opt_key_definition
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2007-03-05 18:08:41 +01:00
|
|
|
if (!($$= Select->add_table_to_list(YYTHD, $2, $3,
|
|
|
|
Select->get_table_join_options(),
|
|
|
|
Lex->lock_option,
|
|
|
|
Select->pop_index_hints())))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2007-03-05 18:08:41 +01:00
|
|
|
Select->add_joined_table($$);
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2005-08-12 16:57:19 +02:00
|
|
|
| '{' ident table_ref LEFT OUTER JOIN_SYM table_ref
|
|
|
|
ON
|
|
|
|
{
|
|
|
|
/* Change the current name resolution context to a local context. */
|
2005-11-28 20:57:50 +01:00
|
|
|
if (push_new_name_resolution_context(YYTHD, $3, $7))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-11-28 20:57:50 +01:00
|
|
|
|
2005-08-12 16:57:19 +02:00
|
|
|
}
|
|
|
|
expr '}'
|
|
|
|
{
|
2006-05-13 20:56:05 +02:00
|
|
|
LEX *lex= Lex;
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($3 && $7);
|
2005-08-12 16:57:19 +02:00
|
|
|
add_join_on($7,$10);
|
|
|
|
Lex->pop_context();
|
|
|
|
$7->outer_join|=JOIN_TYPE_LEFT;
|
|
|
|
$$=$7;
|
2006-05-13 20:56:05 +02:00
|
|
|
if (!($$= lex->current_select->nest_last_join(lex->thd)))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-08-12 16:57:19 +02:00
|
|
|
}
|
2005-03-16 01:13:23 +01:00
|
|
|
| select_derived_init get_select_lex select_derived2
|
2004-09-14 18:28:29 +02:00
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
2005-03-16 01:13:23 +01:00
|
|
|
SELECT_LEX *sel= lex->current_select;
|
|
|
|
if ($1)
|
|
|
|
{
|
|
|
|
if (sel->set_braces(1))
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2005-03-16 01:13:23 +01:00
|
|
|
}
|
|
|
|
/* select in braces, can't contain global parameters */
|
|
|
|
if (sel->master_unit()->fake_select_lex)
|
|
|
|
sel->master_unit()->global_parameters=
|
|
|
|
sel->master_unit()->fake_select_lex;
|
|
|
|
}
|
|
|
|
if ($2->init_nested_join(lex->thd))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-03-16 01:13:23 +01:00
|
|
|
$$= 0;
|
2005-04-04 00:50:05 +02:00
|
|
|
/* incomplete derived tables return NULL, we must be
|
2005-03-16 01:13:23 +01:00
|
|
|
nested in select_derived rule to be here. */
|
2004-09-14 18:28:29 +02:00
|
|
|
}
|
2005-03-16 01:13:23 +01:00
|
|
|
| '(' get_select_lex select_derived union_opt ')' opt_table_alias
|
|
|
|
{
|
|
|
|
/* Use $2 instead of Lex->current_select as derived table will
|
|
|
|
alter value of Lex->current_select. */
|
|
|
|
|
2005-04-04 00:50:05 +02:00
|
|
|
if (!($3 || $6) && $2->embedding &&
|
2005-03-16 01:13:23 +01:00
|
|
|
!$2->embedding->nested_join->join_list.elements)
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2005-03-16 01:13:23 +01:00
|
|
|
/* we have a derived table ($3 == NULL) but no alias,
|
|
|
|
Since we are nested in further parentheses so we
|
|
|
|
can pass NULL to the outer level parentheses
|
|
|
|
Permits parsing of "((((select ...))) as xyz)" */
|
|
|
|
$$= 0;
|
2004-09-14 18:28:29 +02:00
|
|
|
}
|
2005-03-16 01:13:23 +01:00
|
|
|
else
|
|
|
|
if (!$3)
|
|
|
|
{
|
|
|
|
/* Handle case of derived table, alias may be NULL if there
|
|
|
|
are no outer parentheses, add_table_to_list() will throw
|
|
|
|
error in this case */
|
|
|
|
LEX *lex=Lex;
|
|
|
|
SELECT_LEX *sel= lex->current_select;
|
|
|
|
SELECT_LEX_UNIT *unit= sel->master_unit();
|
|
|
|
lex->current_select= sel= unit->outer_select();
|
|
|
|
if (!($$= sel->
|
|
|
|
add_table_to_list(lex->thd, new Table_ident(unit), $6, 0,
|
2007-03-05 18:08:41 +01:00
|
|
|
TL_READ)))
|
2002-12-24 12:58:07 +01:00
|
|
|
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-04-04 00:50:05 +02:00
|
|
|
sel->add_joined_table($$);
|
2005-08-12 16:57:19 +02:00
|
|
|
lex->pop_context();
|
2005-03-16 01:13:23 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
if ($4 || $6)
|
|
|
|
{
|
|
|
|
/* simple nested joins cannot have aliases or unions */
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2005-03-16 01:13:23 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
$$= $3;
|
|
|
|
}
|
|
|
|
;
|
2002-03-26 14:06:05 +01:00
|
|
|
|
2005-03-16 01:13:23 +01:00
|
|
|
/* handle contents of parentheses in join expression */
|
2002-11-28 17:25:41 +01:00
|
|
|
select_derived:
|
2005-03-16 01:13:23 +01:00
|
|
|
get_select_lex
|
2005-02-13 23:35:52 +01:00
|
|
|
{
|
2005-03-16 01:13:23 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
if ($1->init_nested_join(lex->thd))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-03-16 01:13:23 +01:00
|
|
|
}
|
|
|
|
derived_table_list
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
/* for normal joins, $3 != NULL and end_nested_join() != NULL,
|
|
|
|
for derived tables, both must equal NULL */
|
2005-04-04 00:50:05 +02:00
|
|
|
|
2005-03-16 01:13:23 +01:00
|
|
|
if (!($$= $1->end_nested_join(lex->thd)) && $3)
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-03-16 01:13:23 +01:00
|
|
|
if (!$3 && $$)
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2005-03-16 01:13:23 +01:00
|
|
|
}
|
|
|
|
}
|
2005-02-15 16:12:13 +01:00
|
|
|
;
|
2005-02-13 23:35:52 +01:00
|
|
|
|
2005-02-15 18:25:42 +01:00
|
|
|
select_derived2:
|
2002-03-26 14:06:05 +01:00
|
|
|
{
|
2002-05-06 23:04:16 +02:00
|
|
|
LEX *lex= Lex;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->derived_tables|= DERIVED_SUBQUERY;
|
2007-06-11 11:38:37 +02:00
|
|
|
if (!lex->expr_allows_subselect ||
|
|
|
|
lex->sql_command == (int)SQLCOM_PURGE)
|
2004-02-12 18:37:15 +01:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2003-01-09 21:17:16 +01:00
|
|
|
}
|
2002-12-04 23:14:51 +01:00
|
|
|
if (lex->current_select->linkage == GLOBAL_OPTIONS_TYPE ||
|
2002-05-06 23:04:16 +02:00
|
|
|
mysql_new_select(lex, 1))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-03-26 14:06:05 +01:00
|
|
|
mysql_init_select(lex);
|
2002-10-30 12:18:52 +01:00
|
|
|
lex->current_select->linkage= DERIVED_TABLE_TYPE;
|
2004-08-13 09:01:30 +02:00
|
|
|
lex->current_select->parsing_place= SELECT_LIST;
|
2004-02-02 13:58:36 +01:00
|
|
|
}
|
|
|
|
select_options select_item_list
|
|
|
|
{
|
2004-08-13 09:01:30 +02:00
|
|
|
Select->parsing_place= NO_MATTER;
|
2002-03-26 14:06:05 +01:00
|
|
|
}
|
2005-02-13 23:35:52 +01:00
|
|
|
opt_select_from
|
2002-11-28 17:25:41 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-03-16 01:13:23 +01:00
|
|
|
get_select_lex:
|
|
|
|
/* Empty */ { $$= Select; }
|
|
|
|
;
|
|
|
|
|
|
|
|
select_derived_init:
|
|
|
|
SELECT_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-10-12 16:02:57 +02:00
|
|
|
|
|
|
|
if (! lex->parsing_options.allows_derived)
|
|
|
|
{
|
|
|
|
my_error(ER_VIEW_SELECT_DERIVED, MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-10-12 16:02:57 +02:00
|
|
|
}
|
|
|
|
|
2005-04-04 00:50:05 +02:00
|
|
|
SELECT_LEX *sel= lex->current_select;
|
2005-03-16 01:13:23 +01:00
|
|
|
TABLE_LIST *embedding;
|
|
|
|
if (!sel->embedding || sel->end_nested_join(lex->thd))
|
|
|
|
{
|
|
|
|
/* we are not in parentheses */
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2005-03-16 01:13:23 +01:00
|
|
|
}
|
|
|
|
embedding= Select->embedding;
|
|
|
|
$$= embedding &&
|
|
|
|
!embedding->nested_join->join_list.elements;
|
|
|
|
/* return true if we are deeply nested */
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
opt_outer:
|
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| OUTER {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2007-03-05 18:08:41 +01:00
|
|
|
index_hint_clause:
|
|
|
|
/* empty */
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2007-03-05 18:08:41 +01:00
|
|
|
$$= global_system_variables.old_mode ?
|
|
|
|
INDEX_HINT_MASK_JOIN : INDEX_HINT_MASK_ALL;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2007-03-05 18:08:41 +01:00
|
|
|
| FOR_SYM JOIN_SYM { $$= INDEX_HINT_MASK_JOIN; }
|
|
|
|
| FOR_SYM ORDER_SYM BY { $$= INDEX_HINT_MASK_ORDER; }
|
2007-03-11 13:31:43 +01:00
|
|
|
| FOR_SYM GROUP_SYM BY { $$= INDEX_HINT_MASK_GROUP; }
|
2007-03-05 18:08:41 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
index_hint_type:
|
|
|
|
FORCE_SYM { $$= INDEX_HINT_FORCE; }
|
|
|
|
| IGNORE_SYM { $$= INDEX_HINT_IGNORE; }
|
|
|
|
;
|
|
|
|
|
|
|
|
index_hint_definition:
|
|
|
|
index_hint_type key_or_index index_hint_clause
|
2003-01-09 21:42:31 +01:00
|
|
|
{
|
2007-03-05 18:08:41 +01:00
|
|
|
Select->set_index_hint_type($1, $3);
|
2003-01-09 21:42:31 +01:00
|
|
|
}
|
2007-03-19 20:44:46 +01:00
|
|
|
'(' key_usage_list ')'
|
2007-03-05 18:08:41 +01:00
|
|
|
| USE_SYM key_or_index index_hint_clause
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2007-03-05 18:08:41 +01:00
|
|
|
Select->set_index_hint_type(INDEX_HINT_USE, $3);
|
|
|
|
}
|
2007-03-19 20:44:46 +01:00
|
|
|
'(' opt_key_usage_list ')'
|
|
|
|
;
|
2007-03-05 18:08:41 +01:00
|
|
|
|
|
|
|
index_hints_list:
|
|
|
|
index_hint_definition
|
|
|
|
| index_hints_list index_hint_definition
|
2003-01-09 21:42:31 +01:00
|
|
|
;
|
2007-03-05 18:08:41 +01:00
|
|
|
|
|
|
|
opt_index_hints_list:
|
|
|
|
/* empty */
|
|
|
|
| { Select->alloc_index_hints(YYTHD); } index_hints_list
|
2003-01-09 21:42:31 +01:00
|
|
|
;
|
2007-03-05 18:08:41 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
opt_key_definition:
|
2007-03-05 18:08:41 +01:00
|
|
|
{ Select->clear_index_hints(); }
|
|
|
|
opt_index_hints_list
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2007-03-05 18:08:41 +01:00
|
|
|
opt_key_usage_list:
|
|
|
|
/* empty */ { Select->add_index_hint(YYTHD, NULL, 0); }
|
|
|
|
| key_usage_list {}
|
2003-01-09 21:42:31 +01:00
|
|
|
;
|
|
|
|
|
2007-03-05 18:08:41 +01:00
|
|
|
key_usage_element:
|
|
|
|
ident { Select->add_index_hint(YYTHD, $1.str, $1.length); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| PRIMARY_SYM
|
2007-03-05 18:08:41 +01:00
|
|
|
{
|
|
|
|
Select->add_index_hint(YYTHD, (char *)"PRIMARY", 7);
|
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2007-03-05 18:08:41 +01:00
|
|
|
key_usage_list:
|
|
|
|
key_usage_element
|
|
|
|
| key_usage_list ',' key_usage_element
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
using_list:
|
|
|
|
ident
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2005-08-12 16:57:19 +02:00
|
|
|
if (!($$= new List<String>))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-08-12 16:57:19 +02:00
|
|
|
$$->push_back(new (YYTHD->mem_root)
|
|
|
|
String((const char *) $1.str, $1.length,
|
|
|
|
system_charset_info));
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
| using_list ',' ident
|
|
|
|
{
|
2005-08-12 16:57:19 +02:00
|
|
|
$1->push_back(new (YYTHD->mem_root)
|
|
|
|
String((const char *) $3.str, $3.length,
|
|
|
|
system_charset_info));
|
|
|
|
$$= $1;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
interval:
|
2004-11-12 04:01:46 +01:00
|
|
|
interval_time_st {}
|
|
|
|
| DAY_HOUR_SYM { $$=INTERVAL_DAY_HOUR; }
|
2003-06-23 09:56:44 +02:00
|
|
|
| DAY_MICROSECOND_SYM { $$=INTERVAL_DAY_MICROSECOND; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| DAY_MINUTE_SYM { $$=INTERVAL_DAY_MINUTE; }
|
|
|
|
| DAY_SECOND_SYM { $$=INTERVAL_DAY_SECOND; }
|
2003-06-23 09:56:44 +02:00
|
|
|
| HOUR_MICROSECOND_SYM { $$=INTERVAL_HOUR_MICROSECOND; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| HOUR_MINUTE_SYM { $$=INTERVAL_HOUR_MINUTE; }
|
|
|
|
| HOUR_SECOND_SYM { $$=INTERVAL_HOUR_SECOND; }
|
2003-06-23 09:56:44 +02:00
|
|
|
| MICROSECOND_SYM { $$=INTERVAL_MICROSECOND; }
|
|
|
|
| MINUTE_MICROSECOND_SYM { $$=INTERVAL_MINUTE_MICROSECOND; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| MINUTE_SECOND_SYM { $$=INTERVAL_MINUTE_SECOND; }
|
2004-11-12 04:01:46 +01:00
|
|
|
| SECOND_MICROSECOND_SYM { $$=INTERVAL_SECOND_MICROSECOND; }
|
|
|
|
| YEAR_MONTH_SYM { $$=INTERVAL_YEAR_MONTH; };
|
|
|
|
|
|
|
|
interval_time_st:
|
|
|
|
DAY_SYM { $$=INTERVAL_DAY; }
|
|
|
|
| WEEK_SYM { $$=INTERVAL_WEEK; }
|
|
|
|
| HOUR_SYM { $$=INTERVAL_HOUR; }
|
|
|
|
| FRAC_SECOND_SYM { $$=INTERVAL_MICROSECOND; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| MINUTE_SYM { $$=INTERVAL_MINUTE; }
|
|
|
|
| MONTH_SYM { $$=INTERVAL_MONTH; }
|
2004-11-12 04:01:46 +01:00
|
|
|
| QUARTER_SYM { $$=INTERVAL_QUARTER; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| SECOND_SYM { $$=INTERVAL_SECOND; }
|
2004-08-11 10:27:19 +02:00
|
|
|
| YEAR_SYM { $$=INTERVAL_YEAR; }
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-11-03 13:01:59 +01:00
|
|
|
date_time_type:
|
2004-08-11 10:27:19 +02:00
|
|
|
DATE_SYM {$$=MYSQL_TIMESTAMP_DATE;}
|
|
|
|
| TIME_SYM {$$=MYSQL_TIMESTAMP_TIME;}
|
|
|
|
| DATETIME {$$=MYSQL_TIMESTAMP_DATETIME;}
|
|
|
|
| TIMESTAMP {$$=MYSQL_TIMESTAMP_DATETIME;}
|
|
|
|
;
|
2003-10-20 10:24:18 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
table_alias:
|
|
|
|
/* empty */
|
|
|
|
| AS
|
2002-04-16 01:09:30 +02:00
|
|
|
| EQ;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_table_alias:
|
|
|
|
/* empty */ { $$=0; }
|
|
|
|
| table_alias ident
|
2002-04-16 01:09:30 +02:00
|
|
|
{ $$= (LEX_STRING*) sql_memdup(&$2,sizeof(LEX_STRING)); };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-02-06 15:55:59 +01:00
|
|
|
opt_all:
|
|
|
|
/* empty */
|
|
|
|
| ALL
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
where_clause:
|
2003-07-03 01:30:52 +02:00
|
|
|
/* empty */ { Select->where= 0; }
|
2004-08-31 20:10:57 +02:00
|
|
|
| WHERE
|
|
|
|
{
|
|
|
|
Select->parsing_place= IN_WHERE;
|
|
|
|
}
|
|
|
|
expr
|
2002-11-11 14:57:35 +01:00
|
|
|
{
|
2004-08-31 20:10:57 +02:00
|
|
|
SELECT_LEX *select= Select;
|
|
|
|
select->where= $3;
|
|
|
|
select->parsing_place= NO_MATTER;
|
|
|
|
if ($3)
|
|
|
|
$3->top_level_item();
|
2002-11-11 14:57:35 +01:00
|
|
|
}
|
2002-11-21 14:56:48 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
having_clause:
|
|
|
|
/* empty */
|
2003-05-17 09:05:07 +02:00
|
|
|
| HAVING
|
|
|
|
{
|
2004-08-13 09:01:30 +02:00
|
|
|
Select->parsing_place= IN_HAVING;
|
2003-05-17 09:05:07 +02:00
|
|
|
}
|
|
|
|
expr
|
2002-11-21 14:56:48 +01:00
|
|
|
{
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel= Select;
|
2003-05-17 09:05:07 +02:00
|
|
|
sel->having= $3;
|
2004-08-13 09:01:30 +02:00
|
|
|
sel->parsing_place= NO_MATTER;
|
2002-11-21 14:56:48 +01:00
|
|
|
if ($3)
|
|
|
|
$3->top_level_item();
|
|
|
|
}
|
2002-11-11 14:57:35 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_escape:
|
2005-10-21 03:01:52 +02:00
|
|
|
ESCAPE_SYM simple_expr
|
|
|
|
{
|
|
|
|
Lex->escape_used= TRUE;
|
|
|
|
$$= $2;
|
|
|
|
}
|
2004-06-22 17:27:16 +02:00
|
|
|
| /* empty */
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2005-10-21 03:01:52 +02:00
|
|
|
Lex->escape_used= FALSE;
|
2004-11-12 04:01:46 +01:00
|
|
|
$$= ((YYTHD->variables.sql_mode & MODE_NO_BACKSLASH_ESCAPES) ?
|
|
|
|
new Item_string("", 0, &my_charset_latin1) :
|
|
|
|
new Item_string("\\", 1, &my_charset_latin1));
|
2004-06-22 17:27:16 +02:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
2001-12-17 18:59:20 +01:00
|
|
|
group by statement in select
|
2000-07-31 21:29:14 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
group_clause:
|
|
|
|
/* empty */
|
2007-02-23 21:48:15 +01:00
|
|
|
| GROUP_SYM BY group_list olap_opt;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
group_list:
|
2001-12-10 16:51:07 +01:00
|
|
|
group_list ',' order_ident order_dir
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
{ if (add_group_to_list(YYTHD, $3,(bool) $4)) MYSQL_YYABORT; }
|
2001-12-10 16:51:07 +01:00
|
|
|
| order_ident order_dir
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
{ if (add_group_to_list(YYTHD, $1,(bool) $2)) MYSQL_YYABORT; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-07-16 21:42:53 +02:00
|
|
|
olap_opt:
|
|
|
|
/* empty */ {}
|
2002-07-20 13:51:52 +02:00
|
|
|
| WITH CUBE_SYM
|
2002-07-16 21:42:53 +02:00
|
|
|
{
|
2002-07-24 18:55:08 +02:00
|
|
|
LEX *lex=Lex;
|
2002-10-30 12:18:52 +01:00
|
|
|
if (lex->current_select->linkage == GLOBAL_OPTIONS_TYPE)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_WRONG_USAGE, MYF(0), "WITH CUBE",
|
2002-10-30 12:18:52 +01:00
|
|
|
"global union parameters");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-10-30 12:18:52 +01:00
|
|
|
}
|
2003-07-03 01:30:52 +02:00
|
|
|
lex->current_select->olap= CUBE_TYPE;
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_NOT_SUPPORTED_YET, MYF(0), "CUBE");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT; /* To be deleted in 5.1 */
|
2002-07-16 21:42:53 +02:00
|
|
|
}
|
2002-07-20 13:51:52 +02:00
|
|
|
| WITH ROLLUP_SYM
|
2002-07-16 21:42:53 +02:00
|
|
|
{
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
if (lex->current_select->linkage == GLOBAL_OPTIONS_TYPE)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_WRONG_USAGE, MYF(0), "WITH ROLLUP",
|
2002-10-30 12:18:52 +01:00
|
|
|
"global union parameters");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-10-30 12:18:52 +01:00
|
|
|
}
|
2003-07-03 01:30:52 +02:00
|
|
|
lex->current_select->olap= ROLLUP_TYPE;
|
2002-07-16 21:42:53 +02:00
|
|
|
}
|
2002-07-24 18:55:08 +02:00
|
|
|
;
|
2002-07-16 21:42:53 +02:00
|
|
|
|
2007-01-19 02:37:52 +01:00
|
|
|
/*
|
|
|
|
Order by statement in ALTER TABLE
|
|
|
|
*/
|
|
|
|
|
|
|
|
alter_order_clause:
|
|
|
|
ORDER_SYM BY alter_order_list
|
|
|
|
;
|
|
|
|
|
|
|
|
alter_order_list:
|
|
|
|
alter_order_list ',' alter_order_item
|
|
|
|
| alter_order_item
|
|
|
|
;
|
|
|
|
|
|
|
|
alter_order_item:
|
|
|
|
simple_ident_nospvar order_dir
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
bool ascending= ($2 == 1) ? true : false;
|
|
|
|
if (add_order_to_list(thd, $1, ascending))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2007-01-19 02:37:52 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/*
|
2001-12-17 18:59:20 +01:00
|
|
|
Order by statement in select
|
2000-07-31 21:29:14 +02:00
|
|
|
*/
|
|
|
|
|
2000-11-17 01:36:46 +01:00
|
|
|
opt_order_clause:
|
2000-07-31 21:29:14 +02:00
|
|
|
/* empty */
|
2002-04-16 01:09:30 +02:00
|
|
|
| order_clause;
|
2000-11-17 01:36:46 +01:00
|
|
|
|
|
|
|
order_clause:
|
2002-12-04 23:14:51 +01:00
|
|
|
ORDER_SYM BY
|
|
|
|
{
|
2002-01-02 23:46:43 +01:00
|
|
|
LEX *lex=Lex;
|
2006-04-21 07:15:38 +02:00
|
|
|
SELECT_LEX *sel= lex->current_select;
|
|
|
|
SELECT_LEX_UNIT *unit= sel-> master_unit();
|
|
|
|
if (sel->linkage != GLOBAL_OPTIONS_TYPE &&
|
|
|
|
sel->olap != UNSPECIFIED_OLAP_TYPE)
|
2002-07-24 18:55:08 +02:00
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_WRONG_USAGE, MYF(0),
|
|
|
|
"CUBE/ROLLUP", "ORDER BY");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-07-24 18:55:08 +02:00
|
|
|
}
|
2006-04-21 07:15:38 +02:00
|
|
|
if (lex->sql_command != SQLCOM_ALTER_TABLE && !unit->fake_select_lex)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
A query of the of the form (SELECT ...) ORDER BY order_list is
|
|
|
|
executed in the same way as the query
|
|
|
|
SELECT ... ORDER BY order_list
|
|
|
|
unless the SELECT construct contains ORDER BY or LIMIT clauses.
|
|
|
|
Otherwise we create a fake SELECT_LEX if it has not been created
|
|
|
|
yet.
|
|
|
|
*/
|
|
|
|
SELECT_LEX *first_sl= unit->first_select();
|
2007-04-23 13:16:49 +02:00
|
|
|
if (!unit->is_union() &&
|
2006-04-21 07:15:38 +02:00
|
|
|
(first_sl->order_list.elements ||
|
2006-04-21 17:19:38 +02:00
|
|
|
first_sl->select_limit) &&
|
2006-04-21 07:15:38 +02:00
|
|
|
unit->add_fake_select_lex(lex->thd))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-04-21 07:15:38 +02:00
|
|
|
}
|
2002-04-16 01:09:30 +02:00
|
|
|
} order_list;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
order_list:
|
|
|
|
order_list ',' order_ident order_dir
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
{ if (add_order_to_list(YYTHD, $3,(bool) $4)) MYSQL_YYABORT; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| order_ident order_dir
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
{ if (add_order_to_list(YYTHD, $1,(bool) $2)) MYSQL_YYABORT; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
order_dir:
|
|
|
|
/* empty */ { $$ = 1; }
|
2001-12-10 16:51:07 +01:00
|
|
|
| ASC { $$ =1; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| DESC { $$ =0; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
2003-02-12 20:55:37 +01:00
|
|
|
opt_limit_clause_init:
|
|
|
|
/* empty */
|
|
|
|
{
|
2004-02-04 14:26:41 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
SELECT_LEX *sel= lex->current_select;
|
2005-06-07 12:11:36 +02:00
|
|
|
sel->offset_limit= 0;
|
|
|
|
sel->select_limit= 0;
|
2003-02-12 20:55:37 +01:00
|
|
|
}
|
2002-12-01 17:10:13 +01:00
|
|
|
| limit_clause {}
|
|
|
|
;
|
|
|
|
|
2003-02-12 20:55:37 +01:00
|
|
|
opt_limit_clause:
|
|
|
|
/* empty */ {}
|
|
|
|
| limit_clause {}
|
|
|
|
;
|
|
|
|
|
2002-12-01 17:10:13 +01:00
|
|
|
limit_clause:
|
2003-06-04 17:28:51 +02:00
|
|
|
LIMIT limit_options {}
|
2002-11-21 14:56:48 +01:00
|
|
|
;
|
2002-11-16 19:19:10 +01:00
|
|
|
|
|
|
|
limit_options:
|
2005-06-07 12:11:36 +02:00
|
|
|
limit_option
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel= Select;
|
2002-11-16 19:19:10 +01:00
|
|
|
sel->select_limit= $1;
|
2005-06-07 12:11:36 +02:00
|
|
|
sel->offset_limit= 0;
|
2004-05-05 20:21:41 +02:00
|
|
|
sel->explicit_limit= 1;
|
2002-11-16 19:19:10 +01:00
|
|
|
}
|
2005-06-07 12:11:36 +02:00
|
|
|
| limit_option ',' limit_option
|
2002-11-16 19:19:10 +01:00
|
|
|
{
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel= Select;
|
2002-11-16 19:19:10 +01:00
|
|
|
sel->select_limit= $3;
|
|
|
|
sel->offset_limit= $1;
|
2004-05-05 20:21:41 +02:00
|
|
|
sel->explicit_limit= 1;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2005-06-07 12:11:36 +02:00
|
|
|
| limit_option OFFSET_SYM limit_option
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel= Select;
|
2002-11-16 19:19:10 +01:00
|
|
|
sel->select_limit= $1;
|
|
|
|
sel->offset_limit= $3;
|
2004-05-05 20:21:41 +02:00
|
|
|
sel->explicit_limit= 1;
|
2002-11-16 19:19:10 +01:00
|
|
|
}
|
|
|
|
;
|
2005-06-07 12:11:36 +02:00
|
|
|
limit_option:
|
|
|
|
param_marker
|
2007-05-18 09:08:07 +02:00
|
|
|
{
|
|
|
|
((Item_param *) $1)->set_strict_type(INT_RESULT);
|
|
|
|
}
|
2005-06-07 12:11:36 +02:00
|
|
|
| ULONGLONG_NUM { $$= new Item_uint($1.str, $1.length); }
|
|
|
|
| LONG_NUM { $$= new Item_uint($1.str, $1.length); }
|
|
|
|
| NUM { $$= new Item_uint($1.str, $1.length); }
|
2005-06-07 16:48:56 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
delete_limit_clause:
|
|
|
|
/* empty */
|
|
|
|
{
|
2002-01-02 23:46:43 +01:00
|
|
|
LEX *lex=Lex;
|
2005-06-07 12:11:36 +02:00
|
|
|
lex->current_select->select_limit= 0;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2005-06-07 12:11:36 +02:00
|
|
|
| LIMIT limit_option
|
2004-05-05 20:21:41 +02:00
|
|
|
{
|
|
|
|
SELECT_LEX *sel= Select;
|
2005-06-07 12:11:36 +02:00
|
|
|
sel->select_limit= $2;
|
2004-05-05 20:21:41 +02:00
|
|
|
sel->explicit_limit= 1;
|
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-04-04 00:50:05 +02:00
|
|
|
ulong_num:
|
|
|
|
NUM { int error; $$= (ulong) my_strtoll10($1.str, (char**) 0, &error); }
|
2005-06-18 01:55:42 +02:00
|
|
|
| HEX_NUM { $$= (ulong) strtol($1.str, (char**) 0, 16); }
|
2004-05-12 01:38:57 +02:00
|
|
|
| LONG_NUM { int error; $$= (ulong) my_strtoll10($1.str, (char**) 0, &error); }
|
|
|
|
| ULONGLONG_NUM { int error; $$= (ulong) my_strtoll10($1.str, (char**) 0, &error); }
|
2005-04-04 00:50:05 +02:00
|
|
|
| DECIMAL_NUM { int error; $$= (ulong) my_strtoll10($1.str, (char**) 0, &error); }
|
2004-05-12 01:38:57 +02:00
|
|
|
| FLOAT_NUM { int error; $$= (ulong) my_strtoll10($1.str, (char**) 0, &error); }
|
2006-08-07 18:02:28 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
real_ulong_num:
|
|
|
|
NUM { int error; $$= (ulong) my_strtoll10($1.str, (char**) 0, &error); }
|
|
|
|
| HEX_NUM { $$= (ulong) strtol($1.str, (char**) 0, 16); }
|
|
|
|
| LONG_NUM { int error; $$= (ulong) my_strtoll10($1.str, (char**) 0, &error); }
|
|
|
|
| ULONGLONG_NUM { int error; $$= (ulong) my_strtoll10($1.str, (char**) 0, &error); }
|
2007-03-07 11:02:14 +01:00
|
|
|
| dec_num_error { MYSQL_YYABORT; }
|
2006-08-07 18:02:28 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-09-14 01:54:33 +02:00
|
|
|
ulonglong_num:
|
2004-05-12 01:38:57 +02:00
|
|
|
NUM { int error; $$= (ulonglong) my_strtoll10($1.str, (char**) 0, &error); }
|
|
|
|
| ULONGLONG_NUM { int error; $$= (ulonglong) my_strtoll10($1.str, (char**) 0, &error); }
|
|
|
|
| LONG_NUM { int error; $$= (ulonglong) my_strtoll10($1.str, (char**) 0, &error); }
|
2005-02-08 23:50:45 +01:00
|
|
|
| DECIMAL_NUM { int error; $$= (ulonglong) my_strtoll10($1.str, (char**) 0, &error); }
|
2004-05-12 01:38:57 +02:00
|
|
|
| FLOAT_NUM { int error; $$= (ulonglong) my_strtoll10($1.str, (char**) 0, &error); }
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2006-08-07 18:02:28 +02:00
|
|
|
real_ulonglong_num:
|
|
|
|
NUM { int error; $$= (ulonglong) my_strtoll10($1.str, (char**) 0, &error); }
|
|
|
|
| ULONGLONG_NUM { int error; $$= (ulonglong) my_strtoll10($1.str, (char**) 0, &error); }
|
|
|
|
| LONG_NUM { int error; $$= (ulonglong) my_strtoll10($1.str, (char**) 0, &error); }
|
2007-03-07 11:02:14 +01:00
|
|
|
| dec_num_error { MYSQL_YYABORT; }
|
2006-08-07 18:02:28 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
dec_num_error:
|
|
|
|
dec_num
|
2007-03-07 14:08:36 +01:00
|
|
|
{ my_parse_error(ER(ER_ONLY_INTEGERS_ALLOWED)); }
|
2006-08-07 18:02:28 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
dec_num:
|
|
|
|
DECIMAL_NUM
|
|
|
|
| FLOAT_NUM
|
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
procedure_clause:
|
|
|
|
/* empty */
|
|
|
|
| PROCEDURE ident /* Procedure name */
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2006-10-12 16:02:57 +02:00
|
|
|
|
|
|
|
if (! lex->parsing_options.allows_select_procedure)
|
|
|
|
{
|
|
|
|
my_error(ER_VIEW_SELECT_CLAUSE, MYF(0), "PROCEDURE");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-10-12 16:02:57 +02:00
|
|
|
}
|
|
|
|
|
2002-12-05 23:40:28 +01:00
|
|
|
if (&lex->select_lex != lex->current_select)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_WRONG_USAGE, MYF(0), "PROCEDURE", "subquery");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-12-05 23:40:28 +01:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
lex->proc_list.elements=0;
|
|
|
|
lex->proc_list.first=0;
|
WL#3817: Simplify string / memory area types and make things more consistent (first part)
The following type conversions was done:
- Changed byte to uchar
- Changed gptr to uchar*
- Change my_string to char *
- Change my_size_t to size_t
- Change size_s to size_t
Removed declaration of byte, gptr, my_string, my_size_t and size_s.
Following function parameter changes was done:
- All string functions in mysys/strings was changed to use size_t
instead of uint for string lengths.
- All read()/write() functions changed to use size_t (including vio).
- All protocoll functions changed to use size_t instead of uint
- Functions that used a pointer to a string length was changed to use size_t*
- Changed malloc(), free() and related functions from using gptr to use void *
as this requires fewer casts in the code and is more in line with how the
standard functions work.
- Added extra length argument to dirname_part() to return the length of the
created string.
- Changed (at least) following functions to take uchar* as argument:
- db_dump()
- my_net_write()
- net_write_command()
- net_store_data()
- DBUG_DUMP()
- decimal2bin() & bin2decimal()
- Changed my_compress() and my_uncompress() to use size_t. Changed one
argument to my_uncompress() from a pointer to a value as we only return
one value (makes function easier to use).
- Changed type of 'pack_data' argument to packfrm() to avoid casts.
- Changed in readfrm() and writefrom(), ha_discover and handler::discover()
the type for argument 'frmdata' to uchar** to avoid casts.
- Changed most Field functions to use uchar* instead of char* (reduced a lot of
casts).
- Changed field->val_xxx(xxx, new_ptr) to take const pointers.
Other changes:
- Removed a lot of not needed casts
- Added a few new cast required by other changes
- Added some cast to my_multi_malloc() arguments for safety (as string lengths
needs to be uint, not size_t).
- Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
explicitely as this conflict was often hided by casting the function to
hash_get_key).
- Changed some buffers to memory regions to uchar* to avoid casts.
- Changed some string lengths from uint to size_t.
- Changed field->ptr to be uchar* instead of char*. This allowed us to
get rid of a lot of casts.
- Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
- Include zlib.h in some files as we needed declaration of crc32()
- Changed MY_FILE_ERROR to be (size_t) -1.
- Changed many variables to hold the result of my_read() / my_write() to be
size_t. This was needed to properly detect errors (which are
returned as (size_t) -1).
- Removed some very old VMS code
- Changed packfrm()/unpackfrm() to not be depending on uint size
(portability fix)
- Removed windows specific code to restore cursor position as this
causes slowdown on windows and we should not mix read() and pread()
calls anyway as this is not thread safe. Updated function comment to
reflect this. Changed function that depended on original behavior of
my_pwrite() to itself restore the cursor position (one such case).
- Added some missing checking of return value of malloc().
- Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
- Changed type of table_def::m_size from my_size_t to ulong to reflect that
m_size is the number of elements in the array, not a string/memory
length.
- Moved THD::max_row_length() to table.cc (as it's not depending on THD).
Inlined max_row_length_blob() into this function.
- More function comments
- Fixed some compiler warnings when compiled without partitions.
- Removed setting of LEX_STRING() arguments in declaration (portability fix).
- Some trivial indentation/variable name changes.
- Some trivial code simplifications:
- Replaced some calls to alloc_root + memcpy to use
strmake_root()/strdup_root().
- Changed some calls from memdup() to strmake() (Safety fix)
- Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
|
|
|
lex->proc_list.next= (uchar**) &lex->proc_list.first;
|
2005-07-01 06:05:42 +02:00
|
|
|
if (add_proc_to_list(lex->thd, new Item_field(&lex->
|
|
|
|
current_select->
|
|
|
|
context,
|
|
|
|
NULL,NULL,$2.str)))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-11-18 21:04:01 +01:00
|
|
|
Lex->uncacheable(UNCACHEABLE_SIDEEFFECT);
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-04-16 01:09:30 +02:00
|
|
|
'(' procedure_list ')';
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
procedure_list:
|
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| procedure_list2 {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
procedure_list2:
|
|
|
|
procedure_list2 ',' procedure_item
|
2002-04-16 01:09:30 +02:00
|
|
|
| procedure_item;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
procedure_item:
|
2007-06-13 15:31:41 +02:00
|
|
|
remember_name expr remember_end
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
|
|
|
|
if (add_proc_to_list(thd, $2))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
if (!$2->name)
|
2007-06-13 15:31:41 +02:00
|
|
|
$2->set_name($1, (uint) ($3 - $1), thd->charset());
|
2002-10-16 15:55:08 +02:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
select_var_list_init:
|
|
|
|
{
|
2002-10-16 20:17:57 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
if (!lex->describe && (!(lex->result= new select_dumpvar())))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-10-16 15:55:08 +02:00
|
|
|
}
|
2002-12-04 23:14:51 +01:00
|
|
|
select_var_list
|
2002-12-07 12:35:57 +01:00
|
|
|
{}
|
2002-10-16 15:55:08 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-10-11 20:49:10 +02:00
|
|
|
select_var_list:
|
2002-10-16 15:55:08 +02:00
|
|
|
select_var_list ',' select_var_ident
|
|
|
|
| select_var_ident {}
|
|
|
|
;
|
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
select_var_ident:
|
|
|
|
'@' ident_or_text
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
if (lex->result)
|
|
|
|
((select_dumpvar *)lex->result)->var_list.push_back( new my_var($2,0,0,(enum_field_types)0));
|
|
|
|
else
|
2006-05-03 16:02:43 +02:00
|
|
|
/*
|
|
|
|
The parser won't create select_result instance only
|
|
|
|
if it's an EXPLAIN.
|
|
|
|
*/
|
|
|
|
DBUG_ASSERT(lex->describe);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
| ident_or_text
|
2002-10-11 20:49:10 +02:00
|
|
|
{
|
2002-10-16 15:55:08 +02:00
|
|
|
LEX *lex=Lex;
|
2006-04-07 16:53:15 +02:00
|
|
|
sp_variable_t *t;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2006-04-07 16:53:15 +02:00
|
|
|
if (!lex->spcont || !(t=lex->spcont->find_variable(&$1)))
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_SP_UNDECLARED_VAR, MYF(0), $1.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2006-05-03 16:02:43 +02:00
|
|
|
if (lex->result)
|
|
|
|
{
|
2005-11-22 23:50:37 +01:00
|
|
|
my_var *var;
|
|
|
|
((select_dumpvar *)lex->result)->
|
|
|
|
var_list.push_back(var= new my_var($1,1,t->offset,t->type));
|
2005-11-23 11:26:07 +01:00
|
|
|
#ifndef DBUG_OFF
|
2005-11-22 23:50:37 +01:00
|
|
|
if (var)
|
2005-12-07 15:01:17 +01:00
|
|
|
var->sp= lex->sphead;
|
2005-11-22 23:50:37 +01:00
|
|
|
#endif
|
2006-05-03 16:02:43 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
The parser won't create select_result instance only
|
|
|
|
if it's an EXPLAIN.
|
|
|
|
*/
|
|
|
|
DBUG_ASSERT(lex->describe);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2002-10-11 20:49:10 +02:00
|
|
|
}
|
2002-10-16 20:17:57 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-11-28 17:25:41 +01:00
|
|
|
into:
|
2006-10-12 16:02:57 +02:00
|
|
|
INTO
|
|
|
|
{
|
|
|
|
if (! Lex->parsing_options.allows_select_into)
|
|
|
|
{
|
|
|
|
my_error(ER_VIEW_SELECT_CLAUSE, MYF(0), "INTO");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-10-12 16:02:57 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
into_destination
|
|
|
|
;
|
|
|
|
|
|
|
|
into_destination:
|
|
|
|
OUTFILE TEXT_STRING_filesystem
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-10-10 12:29:06 +02:00
|
|
|
LEX *lex= Lex;
|
2004-10-10 11:40:24 +02:00
|
|
|
lex->uncacheable(UNCACHEABLE_SIDEEFFECT);
|
2006-10-12 16:02:57 +02:00
|
|
|
if (!(lex->exchange= new sql_exchange($2.str, 0)) ||
|
2004-10-10 11:40:24 +02:00
|
|
|
!(lex->result= new select_export(lex->exchange)))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
opt_field_term opt_line_term
|
2006-10-12 16:02:57 +02:00
|
|
|
| DUMPFILE TEXT_STRING_filesystem
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2002-10-16 15:55:08 +02:00
|
|
|
LEX *lex=Lex;
|
2002-10-16 20:17:57 +02:00
|
|
|
if (!lex->describe)
|
|
|
|
{
|
2003-11-18 21:04:01 +01:00
|
|
|
lex->uncacheable(UNCACHEABLE_SIDEEFFECT);
|
2006-10-12 16:02:57 +02:00
|
|
|
if (!(lex->exchange= new sql_exchange($2.str,1)))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-10-16 20:17:57 +02:00
|
|
|
if (!(lex->result= new select_dump(lex->exchange)))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-10-16 20:17:57 +02:00
|
|
|
}
|
2002-10-11 20:49:10 +02:00
|
|
|
}
|
2006-10-12 16:02:57 +02:00
|
|
|
| select_var_list_init
|
2002-10-11 20:49:10 +02:00
|
|
|
{
|
2003-11-18 21:04:01 +01:00
|
|
|
Lex->uncacheable(UNCACHEABLE_SIDEEFFECT);
|
2002-10-16 15:55:08 +02:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-12-17 18:59:20 +01:00
|
|
|
/*
|
|
|
|
DO statement
|
|
|
|
*/
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-12-04 23:14:51 +01:00
|
|
|
do: DO_SYM
|
2001-12-17 18:59:20 +01:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command = SQLCOM_DO;
|
2004-11-16 11:36:25 +01:00
|
|
|
mysql_init_select(lex);
|
|
|
|
}
|
|
|
|
expr_list
|
|
|
|
{
|
|
|
|
Lex->insert_list= $3;
|
2001-12-17 18:59:20 +01:00
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/*
|
2003-06-06 14:43:23 +02:00
|
|
|
Drop : delete tables or index or user
|
2000-07-31 21:29:14 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
drop:
|
2003-08-05 21:14:15 +02:00
|
|
|
DROP opt_temporary table_or_tables if_exists table_list opt_restrict
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command = SQLCOM_DROP_TABLE;
|
2002-11-07 03:02:37 +01:00
|
|
|
lex->drop_temporary= $2;
|
|
|
|
lex->drop_if_exists= $4;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2004-06-23 12:29:05 +02:00
|
|
|
| DROP INDEX_SYM ident ON table_ident {}
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_DROP_INDEX;
|
5.1 version of a fix and test cases for bugs:
Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a
growing key length" (this bug is not fixed in 5.0)
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.
Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
2007-05-28 13:30:01 +02:00
|
|
|
lex->alter_info.reset();
|
|
|
|
lex->alter_info.flags= ALTER_DROP_INDEX;
|
2004-05-21 16:57:03 +02:00
|
|
|
lex->alter_info.drop_list.push_back(new Alter_drop(Alter_drop::KEY,
|
|
|
|
$3.str));
|
2003-01-09 02:55:26 +01:00
|
|
|
if (!lex->current_select->add_table_to_list(lex->thd, $5, NULL,
|
|
|
|
TL_OPTION_UPDATING))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
| DROP DATABASE if_exists ident
|
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_DROP_DB;
|
|
|
|
lex->drop_if_exists=$3;
|
2006-10-16 18:57:33 +02:00
|
|
|
lex->name= $4;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
| DROP FUNCTION_SYM if_exists sp_name
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
2004-11-12 04:01:46 +01:00
|
|
|
if (lex->sphead)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_SP_NO_DROP_SP, MYF(0), "FUNCTION");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2001-06-15 04:03:15 +02:00
|
|
|
lex->sql_command = SQLCOM_DROP_FUNCTION;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->drop_if_exists= $3;
|
|
|
|
lex->spname= $4;
|
|
|
|
}
|
|
|
|
| DROP PROCEDURE if_exists sp_name
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
if (lex->sphead)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_SP_NO_DROP_SP, MYF(0), "PROCEDURE");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
lex->sql_command = SQLCOM_DROP_PROCEDURE;
|
|
|
|
lex->drop_if_exists= $3;
|
|
|
|
lex->spname= $4;
|
2003-06-06 14:43:23 +02:00
|
|
|
}
|
2004-11-25 21:55:49 +01:00
|
|
|
| DROP USER clear_privileges user_list
|
2003-06-06 14:43:23 +02:00
|
|
|
{
|
2004-11-25 21:55:49 +01:00
|
|
|
Lex->sql_command = SQLCOM_DROP_USER;
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
| DROP VIEW_SYM if_exists table_list opt_restrict
|
|
|
|
{
|
2005-11-16 13:09:06 +01:00
|
|
|
LEX *lex= Lex;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->sql_command= SQLCOM_DROP_VIEW;
|
|
|
|
lex->drop_if_exists= $3;
|
|
|
|
}
|
2005-12-02 13:07:02 +01:00
|
|
|
| DROP EVENT_SYM if_exists sp_name
|
|
|
|
{
|
2006-06-27 11:51:11 +02:00
|
|
|
Lex->drop_if_exists= $3;
|
|
|
|
Lex->spname= $4;
|
|
|
|
Lex->sql_command = SQLCOM_DROP_EVENT;
|
2005-12-02 13:07:02 +01:00
|
|
|
}
|
Bug#23703 (DROP TRIGGER needs an IF EXISTS)
This change set implements the DROP TRIGGER IF EXISTS functionality.
This fix is considered a bug and not a feature, because without it,
there is no known method to write a database creation script that can create
a trigger without failing, when executed on a database that may or may not
contain already a trigger of the same name.
Implementing this functionality closes an orthogonality gap between triggers
and stored procedures / stored functions (which do support the DROP IF
EXISTS syntax).
In sql_trigger.cc, in mysql_create_or_drop_trigger,
the code has been reordered to:
- perform the tests that do not depend on the file system (access()),
- get the locks (wait_if_global_read_lock, LOCK_open)
- call access()
- perform the operation
- write to the binlog
- unlock (LOCK_open, start_waiting_global_read_lock)
This is to ensure that all the code that depends on the presence of the
trigger file is executed in the same critical section,
and prevents race conditions similar to the case fixed by Bug 14262 :
- thread 1 executes DROP TRIGGER IF EXISTS, access() returns a failure
- thread 2 executes CREATE TRIGGER
- thread 2 logs CREATE TRIGGER
- thread 1 logs DROP TRIGGER IF EXISTS
The patch itself is based on code contributed by the MySQL community,
under the terms of the Contributor License Agreement (See Bug 18161).
2006-11-13 23:40:22 +01:00
|
|
|
| DROP TRIGGER_SYM if_exists sp_name
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command= SQLCOM_DROP_TRIGGER;
|
Bug#23703 (DROP TRIGGER needs an IF EXISTS)
This change set implements the DROP TRIGGER IF EXISTS functionality.
This fix is considered a bug and not a feature, because without it,
there is no known method to write a database creation script that can create
a trigger without failing, when executed on a database that may or may not
contain already a trigger of the same name.
Implementing this functionality closes an orthogonality gap between triggers
and stored procedures / stored functions (which do support the DROP IF
EXISTS syntax).
In sql_trigger.cc, in mysql_create_or_drop_trigger,
the code has been reordered to:
- perform the tests that do not depend on the file system (access()),
- get the locks (wait_if_global_read_lock, LOCK_open)
- call access()
- perform the operation
- write to the binlog
- unlock (LOCK_open, start_waiting_global_read_lock)
This is to ensure that all the code that depends on the presence of the
trigger file is executed in the same critical section,
and prevents race conditions similar to the case fixed by Bug 14262 :
- thread 1 executes DROP TRIGGER IF EXISTS, access() returns a failure
- thread 2 executes CREATE TRIGGER
- thread 2 logs CREATE TRIGGER
- thread 1 logs DROP TRIGGER IF EXISTS
The patch itself is based on code contributed by the MySQL community,
under the terms of the Contributor License Agreement (See Bug 18161).
2006-11-13 23:40:22 +01:00
|
|
|
lex->drop_if_exists= $3;
|
|
|
|
lex->spname= $4;
|
2006-01-11 11:35:25 +01:00
|
|
|
}
|
|
|
|
| DROP TABLESPACE tablespace_name opt_ts_engine opt_ts_wait
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->ts_cmd_type= DROP_TABLESPACE;
|
|
|
|
}
|
2007-02-23 21:48:15 +01:00
|
|
|
| DROP LOGFILE_SYM GROUP_SYM logfile_group_name opt_ts_engine opt_ts_wait
|
2006-01-11 11:35:25 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->alter_tablespace_info->ts_cmd_type= DROP_LOGFILE_GROUP;
|
2006-11-30 00:36:18 +01:00
|
|
|
}
|
2006-12-02 01:47:45 +01:00
|
|
|
| DROP SERVER_SYM if_exists ident_or_text
|
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_DROP_SERVER;
|
|
|
|
Lex->drop_if_exists= $3;
|
|
|
|
Lex->server_options.server_name= $4.str;
|
|
|
|
Lex->server_options.server_name_length= $4.length;
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
table_list:
|
2001-04-07 00:18:33 +02:00
|
|
|
table_name
|
2002-04-16 01:09:30 +02:00
|
|
|
| table_list ',' table_name;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-04-07 00:18:33 +02:00
|
|
|
table_name:
|
2000-07-31 21:29:14 +02:00
|
|
|
table_ident
|
2003-01-09 02:55:26 +01:00
|
|
|
{
|
|
|
|
if (!Select->add_table_to_list(YYTHD, $1, NULL, TL_OPTION_UPDATING))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-01-09 02:55:26 +01:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
if_exists:
|
2002-11-24 14:47:19 +01:00
|
|
|
/* empty */ { $$= 0; }
|
2002-11-07 03:02:37 +01:00
|
|
|
| IF EXISTS { $$= 1; }
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-11-07 03:02:37 +01:00
|
|
|
opt_temporary:
|
|
|
|
/* empty */ { $$= 0; }
|
|
|
|
| TEMPORARY { $$= 1; }
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
/*
|
|
|
|
** Insert : add new data to table
|
|
|
|
*/
|
|
|
|
|
|
|
|
insert:
|
2002-11-26 00:00:05 +01:00
|
|
|
INSERT
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2004-12-31 11:04:35 +01:00
|
|
|
lex->sql_command= SQLCOM_INSERT;
|
|
|
|
lex->duplicates= DUP_ERROR;
|
2005-01-05 15:48:23 +01:00
|
|
|
mysql_init_select(lex);
|
2002-11-26 00:00:05 +01:00
|
|
|
/* for subselects */
|
|
|
|
lex->lock_option= (using_update_log) ? TL_READ_NO_INSERT : TL_READ;
|
|
|
|
} insert_lock_option
|
2002-11-29 16:17:52 +01:00
|
|
|
opt_ignore insert2
|
2002-11-16 19:19:10 +01:00
|
|
|
{
|
2002-11-21 21:25:53 +01:00
|
|
|
Select->set_lock_for_tables($3);
|
2003-08-18 23:08:08 +02:00
|
|
|
Lex->current_select= &Lex->select_lex;
|
2002-11-16 19:19:10 +01:00
|
|
|
}
|
2002-11-28 17:25:41 +01:00
|
|
|
insert_field_spec opt_insert_update
|
2002-12-07 12:35:57 +01:00
|
|
|
{}
|
2002-11-16 19:19:10 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
replace:
|
2001-11-08 13:17:56 +01:00
|
|
|
REPLACE
|
|
|
|
{
|
2002-11-29 16:17:52 +01:00
|
|
|
LEX *lex=Lex;
|
2001-11-08 13:17:56 +01:00
|
|
|
lex->sql_command = SQLCOM_REPLACE;
|
|
|
|
lex->duplicates= DUP_REPLACE;
|
2005-01-05 15:48:23 +01:00
|
|
|
mysql_init_select(lex);
|
2001-11-08 13:17:56 +01:00
|
|
|
}
|
2002-11-16 19:19:10 +01:00
|
|
|
replace_lock_option insert2
|
|
|
|
{
|
2002-11-21 21:25:53 +01:00
|
|
|
Select->set_lock_for_tables($3);
|
2003-08-18 23:08:08 +02:00
|
|
|
Lex->current_select= &Lex->select_lex;
|
2002-11-16 19:19:10 +01:00
|
|
|
}
|
|
|
|
insert_field_spec
|
2002-11-28 18:57:56 +01:00
|
|
|
{}
|
2002-11-16 19:19:10 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
insert_lock_option:
|
2006-03-15 18:15:52 +01:00
|
|
|
/* empty */
|
|
|
|
{
|
|
|
|
#ifdef HAVE_QUERY_CACHE
|
|
|
|
/*
|
|
|
|
If it is SP we do not allow insert optimisation whan result of
|
|
|
|
insert visible only after the table unlocking but everyone can
|
|
|
|
read table.
|
|
|
|
*/
|
2007-06-03 08:40:00 +02:00
|
|
|
$$= (Lex->sphead ? TL_WRITE_DEFAULT : TL_WRITE_CONCURRENT_INSERT);
|
2006-03-15 18:15:52 +01:00
|
|
|
#else
|
|
|
|
$$= TL_WRITE_CONCURRENT_INSERT;
|
|
|
|
#endif
|
|
|
|
}
|
2002-11-16 19:19:10 +01:00
|
|
|
| LOW_PRIORITY { $$= TL_WRITE_LOW_PRIORITY; }
|
|
|
|
| DELAYED_SYM { $$= TL_WRITE_DELAYED; }
|
|
|
|
| HIGH_PRIORITY { $$= TL_WRITE; }
|
2002-11-29 16:17:52 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
replace_lock_option:
|
2002-11-16 19:19:10 +01:00
|
|
|
opt_low_priority { $$= $1; }
|
|
|
|
| DELAYED_SYM { $$= TL_WRITE_DELAYED; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
insert2:
|
|
|
|
INTO insert_table {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| insert_table {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
insert_table:
|
2001-04-07 00:18:33 +02:00
|
|
|
table_name
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->field_list.empty();
|
|
|
|
lex->many_values.empty();
|
|
|
|
lex->insert_list=0;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
insert_field_spec:
|
2003-06-30 22:24:03 +02:00
|
|
|
insert_values {}
|
|
|
|
| '(' ')' insert_values {}
|
|
|
|
| '(' fields ')' insert_values {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| SET
|
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
if (!(lex->insert_list = new List_item) ||
|
|
|
|
lex->many_values.push_back(lex->insert_list))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-04-16 01:09:30 +02:00
|
|
|
ident_eq_list;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
fields:
|
|
|
|
fields ',' insert_ident { Lex->field_list.push_back($3); }
|
2002-04-16 01:09:30 +02:00
|
|
|
| insert_ident { Lex->field_list.push_back($1); };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
insert_values:
|
|
|
|
VALUES values_list {}
|
2002-11-25 11:11:16 +01:00
|
|
|
| VALUE_SYM values_list {}
|
2003-08-18 23:08:08 +02:00
|
|
|
| create_select { Select->set_braces(0);} union_clause {}
|
|
|
|
| '(' create_select ')' { Select->set_braces(1);} union_opt {}
|
2003-06-17 15:20:07 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
values_list:
|
|
|
|
values_list ',' no_braces
|
2002-04-16 01:09:30 +02:00
|
|
|
| no_braces;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
ident_eq_list:
|
|
|
|
ident_eq_list ',' ident_eq_value
|
|
|
|
|
|
2002-04-16 01:09:30 +02:00
|
|
|
ident_eq_value;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
ident_eq_value:
|
2004-11-12 04:01:46 +01:00
|
|
|
simple_ident_nospvar equal expr_or_default
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
if (lex->field_list.push_back($1) ||
|
|
|
|
lex->insert_list->push_back($3))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
equal: EQ {}
|
2002-07-23 17:31:22 +02:00
|
|
|
| SET_VAR {}
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_equal:
|
|
|
|
/* empty */ {}
|
|
|
|
| equal {}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
no_braces:
|
|
|
|
'('
|
|
|
|
{
|
|
|
|
if (!(Lex->insert_list = new List_item))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
opt_values ')'
|
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
if (lex->many_values.push_back(lex->insert_list))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_values:
|
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| values;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
values:
|
2002-07-25 00:00:56 +02:00
|
|
|
values ',' expr_or_default
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
|
|
|
if (Lex->insert_list->push_back($3))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-07-25 00:00:56 +02:00
|
|
|
| expr_or_default
|
|
|
|
{
|
|
|
|
if (Lex->insert_list->push_back($1))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-07-25 00:00:56 +02:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
expr_or_default:
|
2002-11-29 16:17:52 +01:00
|
|
|
expr { $$= $1;}
|
2005-08-12 16:57:19 +02:00
|
|
|
| DEFAULT {$$= new Item_default_value(Lex->current_context()); }
|
2002-07-25 00:00:56 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-11-28 17:25:41 +01:00
|
|
|
opt_insert_update:
|
|
|
|
/* empty */
|
2004-12-30 23:44:00 +01:00
|
|
|
| ON DUPLICATE_SYM { Lex->duplicates= DUP_UPDATE; }
|
2004-12-13 13:26:28 +01:00
|
|
|
KEY_SYM UPDATE_SYM insert_update_list
|
2002-11-28 17:25:41 +01:00
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/* Update rows in a table */
|
|
|
|
|
|
|
|
update:
|
2002-11-29 13:17:54 +01:00
|
|
|
UPDATE_SYM
|
|
|
|
{
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX *lex= Lex;
|
2003-04-05 08:29:28 +02:00
|
|
|
mysql_init_select(lex);
|
2002-10-30 12:18:52 +01:00
|
|
|
lex->sql_command= SQLCOM_UPDATE;
|
2004-02-09 12:31:03 +01:00
|
|
|
lex->lock_option= TL_UNLOCK; /* Will be set later */
|
2004-12-31 11:04:35 +01:00
|
|
|
lex->duplicates= DUP_ERROR;
|
2001-04-11 13:04:03 +02:00
|
|
|
}
|
2002-11-16 19:19:10 +01:00
|
|
|
opt_low_priority opt_ignore join_table_list
|
2004-10-06 18:14:33 +02:00
|
|
|
SET update_list
|
2002-11-16 19:19:10 +01:00
|
|
|
{
|
2002-11-29 14:20:25 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
if (lex->select_lex.table_list.elements > 1)
|
2003-04-05 08:29:28 +02:00
|
|
|
lex->sql_command= SQLCOM_UPDATE_MULTI;
|
2004-01-04 22:44:33 +01:00
|
|
|
else if (lex->select_lex.get_table_list()->derived)
|
|
|
|
{
|
|
|
|
/* it is single table update and it is update of derived table */
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_NON_UPDATABLE_TABLE, MYF(0),
|
|
|
|
lex->select_lex.get_table_list()->alias, "UPDATE");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-01-04 22:44:33 +01:00
|
|
|
}
|
2005-04-15 18:31:47 +02:00
|
|
|
/*
|
|
|
|
In case of multi-update setting write lock for all tables may
|
|
|
|
be too pessimistic. We will decrease lock level if possible in
|
|
|
|
mysql_multi_update().
|
|
|
|
*/
|
|
|
|
Select->set_lock_for_tables($3);
|
2002-11-16 19:19:10 +01:00
|
|
|
}
|
2004-10-03 01:20:47 +02:00
|
|
|
where_clause opt_order_clause delete_limit_clause {}
|
2002-11-16 19:19:10 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
update_list:
|
2004-12-13 13:26:28 +01:00
|
|
|
update_list ',' update_elem
|
|
|
|
| update_elem;
|
|
|
|
|
|
|
|
update_elem:
|
2004-12-22 12:54:39 +01:00
|
|
|
simple_ident_nospvar equal expr_or_default
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-12-30 23:44:00 +01:00
|
|
|
if (add_item_to_list(YYTHD, $1) || add_value_to_list(YYTHD, $3))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-12-13 13:26:28 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
insert_update_list:
|
|
|
|
insert_update_list ',' insert_update_elem
|
|
|
|
| insert_update_elem;
|
|
|
|
|
|
|
|
insert_update_elem:
|
2004-12-22 12:54:39 +01:00
|
|
|
simple_ident_nospvar equal expr_or_default
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-12-13 13:26:28 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
if (lex->update_list.push_back($1) ||
|
|
|
|
lex->value_list.push_back($3))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_low_priority:
|
2007-06-03 08:40:00 +02:00
|
|
|
/* empty */ { $$= TL_WRITE_DEFAULT; }
|
2002-11-16 19:19:10 +01:00
|
|
|
| LOW_PRIORITY { $$= TL_WRITE_LOW_PRIORITY; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
/* Delete rows from a table */
|
|
|
|
|
|
|
|
delete:
|
2000-10-10 21:31:00 +02:00
|
|
|
DELETE_SYM
|
2002-12-04 23:14:51 +01:00
|
|
|
{
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command= SQLCOM_DELETE;
|
2005-01-05 15:48:23 +01:00
|
|
|
mysql_init_select(lex);
|
2007-06-03 08:40:00 +02:00
|
|
|
lex->lock_option= TL_WRITE_DEFAULT;
|
2004-12-31 11:04:35 +01:00
|
|
|
lex->ignore= 0;
|
2002-11-05 00:10:05 +01:00
|
|
|
lex->select_lex.init_order();
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2002-11-16 19:19:10 +01:00
|
|
|
opt_delete_options single_multi {}
|
|
|
|
;
|
2001-06-03 16:07:26 +02:00
|
|
|
|
|
|
|
single_multi:
|
2002-11-16 19:19:10 +01:00
|
|
|
FROM table_ident
|
|
|
|
{
|
2003-01-09 02:55:26 +01:00
|
|
|
if (!Select->add_table_to_list(YYTHD, $2, NULL, TL_OPTION_UPDATING,
|
|
|
|
Lex->lock_option))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-11-16 19:19:10 +01:00
|
|
|
}
|
|
|
|
where_clause opt_order_clause
|
2002-11-28 18:57:56 +01:00
|
|
|
delete_limit_clause {}
|
2001-06-15 04:03:15 +02:00
|
|
|
| table_wild_list
|
2002-01-02 23:46:43 +01:00
|
|
|
{ mysql_init_multi_delete(Lex); }
|
2002-11-16 19:19:10 +01:00
|
|
|
FROM join_table_list where_clause
|
2005-06-08 23:07:52 +02:00
|
|
|
{
|
|
|
|
if (multi_delete_set_locks_and_link_aux_tables(Lex))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-06-08 23:07:52 +02:00
|
|
|
}
|
2002-01-02 23:46:43 +01:00
|
|
|
| FROM table_wild_list
|
|
|
|
{ mysql_init_multi_delete(Lex); }
|
2002-11-28 18:57:56 +01:00
|
|
|
USING join_table_list where_clause
|
2005-06-08 23:07:52 +02:00
|
|
|
{
|
|
|
|
if (multi_delete_set_locks_and_link_aux_tables(Lex))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-06-08 23:07:52 +02:00
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
;
|
2001-06-15 04:03:15 +02:00
|
|
|
|
|
|
|
table_wild_list:
|
|
|
|
table_wild_one {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| table_wild_list ',' table_wild_one {};
|
2001-06-15 04:03:15 +02:00
|
|
|
|
|
|
|
table_wild_one:
|
2002-12-24 12:58:07 +01:00
|
|
|
ident opt_wild opt_table_alias
|
2002-11-21 14:56:48 +01:00
|
|
|
{
|
2003-01-09 02:55:26 +01:00
|
|
|
if (!Select->add_table_to_list(YYTHD, new Table_ident($1), $3,
|
2006-09-04 17:40:30 +02:00
|
|
|
TL_OPTION_UPDATING |
|
|
|
|
TL_OPTION_ALIAS, Lex->lock_option))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-11-21 14:56:48 +01:00
|
|
|
}
|
2002-12-24 12:58:07 +01:00
|
|
|
| ident '.' ident opt_wild opt_table_alias
|
2002-11-21 14:56:48 +01:00
|
|
|
{
|
2003-03-17 14:05:04 +01:00
|
|
|
if (!Select->add_table_to_list(YYTHD,
|
|
|
|
new Table_ident(YYTHD, $1, $3, 0),
|
2006-09-04 17:40:30 +02:00
|
|
|
$5,
|
|
|
|
TL_OPTION_UPDATING |
|
|
|
|
TL_OPTION_ALIAS,
|
2003-01-09 02:55:26 +01:00
|
|
|
Lex->lock_option))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-11-21 14:56:48 +01:00
|
|
|
}
|
2002-11-16 19:19:10 +01:00
|
|
|
;
|
2001-06-15 04:03:15 +02:00
|
|
|
|
|
|
|
opt_wild:
|
2002-12-04 23:14:51 +01:00
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| '.' '*' {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
2000-09-20 03:54:10 +02:00
|
|
|
opt_delete_options:
|
2001-06-15 04:03:15 +02:00
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| opt_delete_option opt_delete_options {};
|
2000-09-20 03:54:10 +02:00
|
|
|
|
|
|
|
opt_delete_option:
|
2001-06-03 16:07:26 +02:00
|
|
|
QUICK { Select->options|= OPTION_QUICK; }
|
2003-11-17 21:45:07 +01:00
|
|
|
| LOW_PRIORITY { Lex->lock_option= TL_WRITE_LOW_PRIORITY; }
|
2004-12-31 11:04:35 +01:00
|
|
|
| IGNORE_SYM { Lex->ignore= 1; };
|
2000-09-20 03:54:10 +02:00
|
|
|
|
2000-11-13 22:55:10 +01:00
|
|
|
truncate:
|
2001-04-15 20:14:40 +02:00
|
|
|
TRUNCATE_SYM opt_table_sym table_name
|
2001-04-11 13:04:03 +02:00
|
|
|
{
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX* lex= Lex;
|
2001-04-11 13:04:03 +02:00
|
|
|
lex->sql_command= SQLCOM_TRUNCATE;
|
2002-10-30 12:18:52 +01:00
|
|
|
lex->select_lex.options= 0;
|
2006-06-27 19:28:32 +02:00
|
|
|
lex->select_lex.sql_cache= SELECT_LEX::SQL_CACHE_UNSPECIFIED;
|
2002-11-05 00:10:05 +01:00
|
|
|
lex->select_lex.init_order();
|
2002-11-16 19:19:10 +01:00
|
|
|
}
|
|
|
|
;
|
2000-11-13 22:55:10 +01:00
|
|
|
|
2001-02-02 02:47:06 +01:00
|
|
|
opt_table_sym:
|
|
|
|
/* empty */
|
2002-04-16 01:09:30 +02:00
|
|
|
| TABLE_SYM;
|
2002-12-04 23:14:51 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/* Show things */
|
|
|
|
|
2002-12-04 23:14:51 +01:00
|
|
|
show: SHOW
|
|
|
|
{
|
2002-11-06 09:01:38 +01:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->wild=0;
|
2005-01-24 16:44:54 +01:00
|
|
|
lex->lock_option= TL_READ;
|
|
|
|
mysql_init_select(lex);
|
|
|
|
lex->current_select->parsing_place= SELECT_LIST;
|
2002-11-06 09:01:38 +01:00
|
|
|
bzero((char*) &lex->create_info,sizeof(lex->create_info));
|
|
|
|
}
|
2002-12-05 18:38:42 +01:00
|
|
|
show_param
|
2002-11-28 18:57:56 +01:00
|
|
|
{}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
show_param:
|
2005-01-24 16:44:54 +01:00
|
|
|
DATABASES wild_and_where
|
2004-11-13 11:56:39 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_DATABASES;
|
2004-11-13 11:56:39 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_SCHEMATA))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-13 11:56:39 +01:00
|
|
|
}
|
2005-01-24 16:44:54 +01:00
|
|
|
| opt_full TABLES opt_db wild_and_where
|
2004-11-13 11:56:39 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_TABLES;
|
2005-01-24 16:44:54 +01:00
|
|
|
lex->select_lex.db= $3;
|
2004-11-13 11:56:39 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_TABLE_NAMES))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-13 11:56:39 +01:00
|
|
|
}
|
2005-07-19 18:06:49 +02:00
|
|
|
| opt_full TRIGGERS_SYM opt_db wild_and_where
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_TRIGGERS;
|
2005-07-19 18:06:49 +02:00
|
|
|
lex->select_lex.db= $3;
|
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_TRIGGERS))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-07-19 18:06:49 +02:00
|
|
|
}
|
2006-05-22 20:46:13 +02:00
|
|
|
| EVENTS_SYM opt_db wild_and_where
|
2006-01-30 13:15:23 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_EVENTS;
|
2006-05-22 20:46:13 +02:00
|
|
|
lex->select_lex.db= $2;
|
2006-01-30 13:15:23 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_EVENTS))
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-01-30 13:15:23 +01:00
|
|
|
}
|
2005-01-24 16:44:54 +01:00
|
|
|
| TABLE_SYM STATUS_SYM opt_db wild_and_where
|
2004-11-13 11:56:39 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_TABLE_STATUS;
|
2005-01-24 16:44:54 +01:00
|
|
|
lex->select_lex.db= $3;
|
2004-11-13 11:56:39 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_TABLES))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-13 11:56:39 +01:00
|
|
|
}
|
2005-01-24 16:44:54 +01:00
|
|
|
| OPEN_SYM TABLES opt_db wild_and_where
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_OPEN_TABLES;
|
2002-10-30 12:18:52 +01:00
|
|
|
lex->select_lex.db= $3;
|
2004-12-30 13:20:40 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_OPEN_TABLES))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-12-18 22:22:20 +01:00
|
|
|
}
|
2006-04-13 22:49:29 +02:00
|
|
|
| opt_full PLUGIN_SYM
|
2006-04-06 15:29:39 +02:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
WARN_DEPRECATED(yythd, "5.2", "SHOW PLUGIN", "'SHOW PLUGINS'");
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_PLUGINS;
|
2006-04-06 15:29:39 +02:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_PLUGINS))
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-04-06 15:29:39 +02:00
|
|
|
}
|
|
|
|
| PLUGINS_SYM
|
2005-12-21 19:18:40 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_PLUGINS;
|
2005-12-21 19:18:40 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_PLUGINS))
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-12-21 19:18:40 +01:00
|
|
|
}
|
Bug#24392 (SHOW ENGINE MUTEX STATUS is a synonym for SHOW INNODB STATUS)
Before this fix, the command SHOW ENGINE <name> STATUS would:
- print a warning if the engine name is unknown,
- proceed and implement the same behavior as SHOW ENGINE ALL STATUS,
and list the status of all the storage engines registered.
In particular, this behavior caused confusion about the command :
SHOW ENGINE MUTEX STATUS, which as a side effect would print the status
of the innodb engine when that engine is registered.
Also, before this fix, every time an unknown engine name was substituted by
the default engine (which happen unless SQL_MODE NO_ENGINE_SUBSTITUTION is
set), a malformed warning was raised.
For example, the command ALTER TABLE T1 ENGINE = X would print :
Warnings:
Error 1286 Unknown table engine 'X'
With this fix:
SHOW ENGINE <name> STATUS|LOGS|MUTEX
always fails with an error when the engine <name> is unknown.
For other commands, warnings about unknown engines are raised as:
Warnings:
Warning 1286 Unknown table engine 'X'
In other words, engine substitution never affect the SHOW ENGINE command,
since this would lead to very confusing results.
2007-01-23 23:14:08 +01:00
|
|
|
| ENGINE_SYM known_storage_engines show_engine_param
|
2003-12-10 05:31:42 +01:00
|
|
|
{ Lex->create_info.db_type= $2; }
|
Bug#24392 (SHOW ENGINE MUTEX STATUS is a synonym for SHOW INNODB STATUS)
Before this fix, the command SHOW ENGINE <name> STATUS would:
- print a warning if the engine name is unknown,
- proceed and implement the same behavior as SHOW ENGINE ALL STATUS,
and list the status of all the storage engines registered.
In particular, this behavior caused confusion about the command :
SHOW ENGINE MUTEX STATUS, which as a side effect would print the status
of the innodb engine when that engine is registered.
Also, before this fix, every time an unknown engine name was substituted by
the default engine (which happen unless SQL_MODE NO_ENGINE_SUBSTITUTION is
set), a malformed warning was raised.
For example, the command ALTER TABLE T1 ENGINE = X would print :
Warnings:
Error 1286 Unknown table engine 'X'
With this fix:
SHOW ENGINE <name> STATUS|LOGS|MUTEX
always fails with an error when the engine <name> is unknown.
For other commands, warnings about unknown engines are raised as:
Warnings:
Warning 1286 Unknown table engine 'X'
In other words, engine substitution never affect the SHOW ENGINE command,
since this would lead to very confusing results.
2007-01-23 23:14:08 +01:00
|
|
|
| ENGINE_SYM ALL show_engine_param
|
2005-12-21 19:18:40 +01:00
|
|
|
{ Lex->create_info.db_type= NULL; }
|
2005-01-24 16:44:54 +01:00
|
|
|
| opt_full COLUMNS from_or_in table_ident opt_db wild_and_where
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_FIELDS;
|
2005-01-24 16:44:54 +01:00
|
|
|
if ($5)
|
|
|
|
$4->change_db($5);
|
|
|
|
if (prepare_schema_table(YYTHD, lex, $4, SCH_COLUMNS))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-12-04 23:14:51 +01:00
|
|
|
| NEW_SYM MASTER_SYM FOR_SYM SLAVE WITH MASTER_LOG_FILE_SYM EQ
|
2004-04-15 09:14:14 +02:00
|
|
|
TEXT_STRING_sys AND_SYM MASTER_LOG_POS_SYM EQ ulonglong_num
|
|
|
|
AND_SYM MASTER_SERVER_ID_SYM EQ
|
2005-04-04 00:50:05 +02:00
|
|
|
ulong_num
|
2001-07-05 01:14:31 +02:00
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_SHOW_NEW_MASTER;
|
|
|
|
Lex->mi.log_file_name = $8.str;
|
|
|
|
Lex->mi.pos = $12;
|
2002-01-20 03:16:52 +01:00
|
|
|
Lex->mi.server_id = $16;
|
2001-07-05 01:14:31 +02:00
|
|
|
}
|
2003-07-12 23:31:21 +02:00
|
|
|
| master_or_binary LOGS_SYM
|
2000-10-27 06:11:55 +02:00
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_SHOW_BINLOGS;
|
2001-05-31 02:50:56 +02:00
|
|
|
}
|
|
|
|
| SLAVE HOSTS_SYM
|
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_SHOW_SLAVE_HOSTS;
|
|
|
|
}
|
2001-12-13 14:53:18 +01:00
|
|
|
| BINLOG_SYM EVENTS_SYM binlog_in binlog_from
|
2001-06-21 21:19:24 +02:00
|
|
|
{
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command= SQLCOM_SHOW_BINLOG_EVENTS;
|
2003-02-12 20:55:37 +01:00
|
|
|
} opt_limit_clause_init
|
2005-01-24 16:44:54 +01:00
|
|
|
| keys_or_index from_or_in table_ident opt_db where_clause
|
2004-11-13 11:56:39 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_KEYS;
|
2005-01-24 16:44:54 +01:00
|
|
|
if ($4)
|
|
|
|
$3->change_db($4);
|
|
|
|
if (prepare_schema_table(YYTHD, lex, $3, SCH_STATISTICS))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-06-12 23:13:12 +02:00
|
|
|
| COLUMN_SYM TYPES_SYM
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_SHOW_COLUMN_TYPES;
|
|
|
|
}
|
|
|
|
| TABLE_SYM TYPES_SYM
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2003-12-17 23:52:03 +01:00
|
|
|
lex->sql_command= SQLCOM_SHOW_STORAGE_ENGINES;
|
2006-03-01 21:36:05 +01:00
|
|
|
WARN_DEPRECATED(yythd, "5.2", "SHOW TABLE TYPES", "'SHOW [STORAGE] ENGINES'");
|
2003-12-17 23:52:03 +01:00
|
|
|
}
|
|
|
|
| opt_storage ENGINES_SYM
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_SHOW_STORAGE_ENGINES;
|
2005-12-22 10:07:47 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_ENGINES))
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
2005-11-10 18:43:17 +01:00
|
|
|
| AUTHORS_SYM
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_SHOW_AUTHORS;
|
|
|
|
}
|
2006-05-03 02:53:26 +02:00
|
|
|
| CONTRIBUTORS_SYM
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_SHOW_CONTRIBUTORS;
|
|
|
|
}
|
2002-06-12 23:13:12 +02:00
|
|
|
| PRIVILEGES
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_SHOW_PRIVILEGES;
|
|
|
|
}
|
2002-12-04 23:14:51 +01:00
|
|
|
| COUNT_SYM '(' '*' ')' WARNINGS
|
2002-10-02 12:33:08 +02:00
|
|
|
{ (void) create_select_for_variable("warning_count"); }
|
2002-12-04 23:14:51 +01:00
|
|
|
| COUNT_SYM '(' '*' ')' ERRORS
|
2002-10-02 12:33:08 +02:00
|
|
|
{ (void) create_select_for_variable("error_count"); }
|
2003-02-12 20:55:37 +01:00
|
|
|
| WARNINGS opt_limit_clause_init
|
2002-06-12 23:13:12 +02:00
|
|
|
{ Lex->sql_command = SQLCOM_SHOW_WARNS;}
|
2003-02-12 20:55:37 +01:00
|
|
|
| ERRORS opt_limit_clause_init
|
2002-12-04 23:14:51 +01:00
|
|
|
{ Lex->sql_command = SQLCOM_SHOW_ERRORS;}
|
2005-01-24 16:44:54 +01:00
|
|
|
| opt_var_type STATUS_SYM wild_and_where
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2004-12-30 13:20:40 +01:00
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_STATUS;
|
2005-08-27 15:51:11 +02:00
|
|
|
lex->option_type= $1;
|
2004-12-30 13:20:40 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_STATUS))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-03-01 21:36:05 +01:00
|
|
|
}
|
2002-07-08 18:34:49 +02:00
|
|
|
| INNOBASE_SYM STATUS_SYM
|
2005-11-07 16:25:06 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command = SQLCOM_SHOW_ENGINE_STATUS;
|
2005-12-21 19:18:40 +01:00
|
|
|
if (!(lex->create_info.db_type=
|
|
|
|
ha_resolve_by_legacy_type(YYTHD, DB_TYPE_INNODB)))
|
|
|
|
{
|
|
|
|
my_error(ER_UNKNOWN_STORAGE_ENGINE, MYF(0), "InnoDB");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-12-21 19:18:40 +01:00
|
|
|
}
|
2006-03-01 21:36:05 +01:00
|
|
|
WARN_DEPRECATED(yythd, "5.2", "SHOW INNODB STATUS", "'SHOW ENGINE INNODB STATUS'");
|
2005-11-07 16:25:06 +01:00
|
|
|
}
|
2004-12-24 12:13:32 +01:00
|
|
|
| MUTEX_SYM STATUS_SYM
|
2005-11-07 16:25:06 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-03-01 21:36:05 +01:00
|
|
|
lex->sql_command = SQLCOM_SHOW_ENGINE_MUTEX;
|
2005-12-21 19:18:40 +01:00
|
|
|
if (!(lex->create_info.db_type=
|
|
|
|
ha_resolve_by_legacy_type(YYTHD, DB_TYPE_INNODB)))
|
|
|
|
{
|
|
|
|
my_error(ER_UNKNOWN_STORAGE_ENGINE, MYF(0), "InnoDB");
|
2007-03-07 11:02:14 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-12-21 19:18:40 +01:00
|
|
|
}
|
2006-03-01 21:36:05 +01:00
|
|
|
WARN_DEPRECATED(yythd, "5.2", "SHOW MUTEX STATUS", "'SHOW ENGINE INNODB MUTEX'");
|
2005-11-07 16:25:06 +01:00
|
|
|
}
|
2001-01-22 04:32:58 +01:00
|
|
|
| opt_full PROCESSLIST_SYM
|
|
|
|
{ Lex->sql_command= SQLCOM_SHOW_PROCESSLIST;}
|
2005-01-24 16:44:54 +01:00
|
|
|
| opt_var_type VARIABLES wild_and_where
|
2002-08-30 11:40:40 +02:00
|
|
|
{
|
2004-12-30 13:20:40 +01:00
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_VARIABLES;
|
2005-08-27 15:51:11 +02:00
|
|
|
lex->option_type= $1;
|
2004-12-30 13:20:40 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_VARIABLES))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-06-28 18:30:09 +02:00
|
|
|
}
|
2005-01-24 16:44:54 +01:00
|
|
|
| charset wild_and_where
|
2004-11-13 11:56:39 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_CHARSETS;
|
2004-11-13 11:56:39 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_CHARSETS))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-13 11:56:39 +01:00
|
|
|
}
|
2005-01-24 16:44:54 +01:00
|
|
|
| COLLATION_SYM wild_and_where
|
2004-11-13 11:56:39 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_COLLATIONS;
|
2004-11-13 11:56:39 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_COLLATIONS))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-13 11:56:39 +01:00
|
|
|
}
|
2004-04-05 14:55:26 +02:00
|
|
|
| GRANTS
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_SHOW_GRANTS;
|
|
|
|
LEX_USER *curr_user;
|
2006-06-29 12:50:44 +02:00
|
|
|
if (!(curr_user= (LEX_USER*) lex->thd->alloc(sizeof(st_lex_user))))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-06-29 12:50:44 +02:00
|
|
|
bzero(curr_user, sizeof(st_lex_user));
|
2004-04-05 14:55:26 +02:00
|
|
|
lex->grant_user= curr_user;
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| GRANTS FOR_SYM user
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_SHOW_GRANTS;
|
|
|
|
lex->grant_user=$3;
|
2005-01-16 13:16:23 +01:00
|
|
|
lex->grant_user->password=null_lex_str;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2002-11-06 09:01:38 +01:00
|
|
|
| CREATE DATABASE opt_if_not_exists ident
|
2002-07-02 11:31:54 +02:00
|
|
|
{
|
|
|
|
Lex->sql_command=SQLCOM_SHOW_CREATE_DB;
|
2002-11-06 09:01:38 +01:00
|
|
|
Lex->create_info.options=$3;
|
2006-10-16 18:57:33 +02:00
|
|
|
Lex->name= $4;
|
2002-07-02 11:31:54 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| CREATE TABLE_SYM table_ident
|
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command = SQLCOM_SHOW_CREATE;
|
|
|
|
if (!lex->select_lex.add_table_to_list(YYTHD, $3, NULL,0))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->only_view= 0;
|
2006-12-19 23:20:43 +01:00
|
|
|
lex->create_info.storage_media= HA_SM_DEFAULT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
| CREATE VIEW_SYM table_ident
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command = SQLCOM_SHOW_CREATE;
|
|
|
|
if (!lex->select_lex.add_table_to_list(YYTHD, $3, NULL, 0))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->only_view= 1;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
| MASTER_SYM STATUS_SYM
|
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_SHOW_MASTER_STAT;
|
2000-08-21 23:39:08 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| SLAVE STATUS_SYM
|
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_SHOW_SLAVE_STAT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
| CREATE PROCEDURE sp_name
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
|
|
|
|
lex->sql_command = SQLCOM_SHOW_CREATE_PROC;
|
|
|
|
lex->spname= $3;
|
|
|
|
}
|
|
|
|
| CREATE FUNCTION_SYM sp_name
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
|
|
|
|
lex->sql_command = SQLCOM_SHOW_CREATE_FUNC;
|
|
|
|
lex->spname= $3;
|
|
|
|
}
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
| CREATE TRIGGER_SYM sp_name
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command= SQLCOM_SHOW_CREATE_TRIGGER;
|
|
|
|
lex->spname= $3;
|
|
|
|
}
|
2005-01-24 16:44:54 +01:00
|
|
|
| PROCEDURE STATUS_SYM wild_and_where
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2004-11-13 11:56:39 +01:00
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_STATUS_PROC;
|
2005-02-08 20:52:50 +01:00
|
|
|
if (!sp_add_to_query_tables(YYTHD, lex, "mysql", "proc", TL_READ))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-13 11:56:39 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_PROCEDURES))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2005-01-24 16:44:54 +01:00
|
|
|
| FUNCTION_SYM STATUS_SYM wild_and_where
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2004-11-13 11:56:39 +01:00
|
|
|
LEX *lex= Lex;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_STATUS_FUNC;
|
2005-02-08 20:52:50 +01:00
|
|
|
if (!sp_add_to_query_tables(YYTHD, lex, "mysql", "proc", TL_READ))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-13 11:56:39 +01:00
|
|
|
if (prepare_schema_table(YYTHD, lex, 0, SCH_PROCEDURES))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-11-17 11:11:48 +01:00
|
|
|
}
|
|
|
|
| PROCEDURE CODE_SYM sp_name
|
|
|
|
{
|
|
|
|
#ifdef DBUG_OFF
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2005-11-17 11:11:48 +01:00
|
|
|
#else
|
|
|
|
Lex->sql_command= SQLCOM_SHOW_PROC_CODE;
|
|
|
|
Lex->spname= $3;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
| FUNCTION_SYM CODE_SYM sp_name
|
|
|
|
{
|
|
|
|
#ifdef DBUG_OFF
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2005-11-17 11:11:48 +01:00
|
|
|
#else
|
|
|
|
Lex->sql_command= SQLCOM_SHOW_FUNC_CODE;
|
|
|
|
Lex->spname= $3;
|
|
|
|
#endif
|
|
|
|
}
|
2005-12-02 13:07:02 +01:00
|
|
|
| CREATE EVENT_SYM sp_name
|
|
|
|
{
|
2005-12-05 11:45:04 +01:00
|
|
|
Lex->spname= $3;
|
2006-06-27 10:53:26 +02:00
|
|
|
Lex->sql_command = SQLCOM_SHOW_CREATE_EVENT;
|
2006-01-11 12:49:56 +01:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-12-10 05:31:42 +01:00
|
|
|
show_engine_param:
|
|
|
|
STATUS_SYM
|
2005-11-07 16:25:06 +01:00
|
|
|
{ Lex->sql_command= SQLCOM_SHOW_ENGINE_STATUS; }
|
|
|
|
| MUTEX_SYM
|
|
|
|
{ Lex->sql_command= SQLCOM_SHOW_ENGINE_MUTEX; }
|
2003-12-10 05:31:42 +01:00
|
|
|
| LOGS_SYM
|
2005-11-07 16:25:06 +01:00
|
|
|
{ Lex->sql_command= SQLCOM_SHOW_ENGINE_LOGS; };
|
2003-12-10 05:31:42 +01:00
|
|
|
|
2003-07-12 23:31:21 +02:00
|
|
|
master_or_binary:
|
|
|
|
MASTER_SYM
|
|
|
|
| BINARY;
|
|
|
|
|
2003-12-17 23:52:03 +01:00
|
|
|
opt_storage:
|
|
|
|
/* empty */
|
|
|
|
| STORAGE_SYM;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
opt_db:
|
|
|
|
/* empty */ { $$= 0; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| from_or_in ident { $$= $2.str; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-01-22 04:32:58 +01:00
|
|
|
opt_full:
|
|
|
|
/* empty */ { Lex->verbose=0; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| FULL { Lex->verbose=1; };
|
2001-01-22 04:32:58 +01:00
|
|
|
|
2001-06-28 09:49:16 +02:00
|
|
|
from_or_in:
|
|
|
|
FROM
|
2002-04-16 01:09:30 +02:00
|
|
|
| IN_SYM;
|
2001-06-28 09:49:16 +02:00
|
|
|
|
2001-06-21 21:19:24 +02:00
|
|
|
binlog_in:
|
|
|
|
/* empty */ { Lex->mi.log_file_name = 0; }
|
2003-03-17 18:56:34 +01:00
|
|
|
| IN_SYM TEXT_STRING_sys { Lex->mi.log_file_name = $2.str; };
|
2001-06-21 21:19:24 +02:00
|
|
|
|
|
|
|
binlog_from:
|
|
|
|
/* empty */ { Lex->mi.pos = 4; /* skip magic number */ }
|
2002-04-16 01:09:30 +02:00
|
|
|
| FROM ulonglong_num { Lex->mi.pos = $2; };
|
2001-06-21 21:19:24 +02:00
|
|
|
|
2004-11-13 11:56:39 +01:00
|
|
|
wild_and_where:
|
|
|
|
/* empty */
|
|
|
|
| LIKE TEXT_STRING_sys
|
|
|
|
{ Lex->wild= new (YYTHD->mem_root) String($2.str, $2.length,
|
|
|
|
system_charset_info); }
|
|
|
|
| WHERE expr
|
|
|
|
{
|
|
|
|
Select->where= $2;
|
|
|
|
if ($2)
|
|
|
|
$2->top_level_item();
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2001-06-21 21:19:24 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/* A Oracle compatible synonym for show */
|
|
|
|
describe:
|
|
|
|
describe_command table_ident
|
|
|
|
{
|
2004-11-13 11:56:39 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->lock_option= TL_READ;
|
|
|
|
mysql_init_select(lex);
|
|
|
|
lex->current_select->parsing_place= SELECT_LIST;
|
2006-06-20 12:20:32 +02:00
|
|
|
lex->sql_command= SQLCOM_SHOW_FIELDS;
|
2004-11-13 11:56:39 +01:00
|
|
|
lex->select_lex.db= 0;
|
|
|
|
lex->verbose= 0;
|
|
|
|
if (prepare_schema_table(YYTHD, lex, $2, SCH_COLUMNS))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
opt_describe_column {}
|
2003-10-16 14:54:47 +02:00
|
|
|
| describe_command opt_extended_describe
|
|
|
|
{ Lex->describe|= DESCRIBE_NORMAL; }
|
|
|
|
select
|
2002-12-04 23:14:51 +01:00
|
|
|
{
|
2002-10-16 20:17:57 +02:00
|
|
|
LEX *lex=Lex;
|
2002-12-04 23:14:51 +01:00
|
|
|
lex->select_lex.options|= SELECT_DESCRIBE;
|
2002-12-05 18:38:42 +01:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
describe_command:
|
|
|
|
DESC
|
2002-04-16 01:09:30 +02:00
|
|
|
| DESCRIBE;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-10-16 14:54:47 +02:00
|
|
|
opt_extended_describe:
|
|
|
|
/* empty */ {}
|
|
|
|
| EXTENDED_SYM { Lex->describe|= DESCRIBE_EXTENDED; }
|
2005-12-22 10:29:00 +01:00
|
|
|
| PARTITIONS_SYM { Lex->describe|= DESCRIBE_PARTITIONS; }
|
2003-10-16 14:54:47 +02:00
|
|
|
;
|
|
|
|
|
2005-12-22 10:29:00 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
opt_describe_column:
|
|
|
|
/* empty */ {}
|
|
|
|
| text_string { Lex->wild= $1; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| ident
|
2004-11-08 00:13:54 +01:00
|
|
|
{ Lex->wild= new (YYTHD->mem_root) String((const char*) $1.str,$1.length,system_charset_info); };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
/* flush things */
|
|
|
|
|
|
|
|
flush:
|
2003-05-15 18:35:39 +02:00
|
|
|
FLUSH_SYM opt_no_write_to_binlog
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2006-08-25 15:51:29 +02:00
|
|
|
lex->sql_command= SQLCOM_FLUSH;
|
|
|
|
lex->type= 0;
|
2003-08-11 21:44:43 +02:00
|
|
|
lex->no_write_to_binlog= $2;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
flush_options
|
|
|
|
{}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
flush_options:
|
|
|
|
flush_options ',' flush_option
|
2002-04-16 01:09:30 +02:00
|
|
|
| flush_option;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
flush_option:
|
2002-11-28 18:57:56 +01:00
|
|
|
table_or_tables { Lex->type|= REFRESH_TABLES; } opt_table_list {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| TABLES WITH READ_SYM LOCK_SYM { Lex->type|= REFRESH_TABLES | REFRESH_READ_LOCK; }
|
2001-12-02 13:34:01 +01:00
|
|
|
| QUERY_SYM CACHE_SYM { Lex->type|= REFRESH_QUERY_CACHE_FREE; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| HOSTS_SYM { Lex->type|= REFRESH_HOSTS; }
|
|
|
|
| PRIVILEGES { Lex->type|= REFRESH_GRANT; }
|
|
|
|
| LOGS_SYM { Lex->type|= REFRESH_LOG; }
|
|
|
|
| STATUS_SYM { Lex->type|= REFRESH_STATUS; }
|
2000-08-21 23:39:08 +02:00
|
|
|
| SLAVE { Lex->type|= REFRESH_SLAVE; }
|
|
|
|
| MASTER_SYM { Lex->type|= REFRESH_MASTER; }
|
2002-06-20 15:46:25 +02:00
|
|
|
| DES_KEY_FILE { Lex->type|= REFRESH_DES_KEY_FILE; }
|
|
|
|
| RESOURCES { Lex->type|= REFRESH_USER_RESOURCES; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2000-08-21 23:18:32 +02:00
|
|
|
opt_table_list:
|
2002-06-20 15:46:25 +02:00
|
|
|
/* empty */ {;}
|
|
|
|
| table_list {;};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2000-10-14 10:16:17 +02:00
|
|
|
reset:
|
2001-06-15 04:03:15 +02:00
|
|
|
RESET_SYM
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_RESET; lex->type=0;
|
2002-11-28 18:57:56 +01:00
|
|
|
} reset_options
|
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
2000-10-14 10:16:17 +02:00
|
|
|
reset_options:
|
|
|
|
reset_options ',' reset_option
|
2002-04-16 01:09:30 +02:00
|
|
|
| reset_option;
|
2000-10-14 10:16:17 +02:00
|
|
|
|
|
|
|
reset_option:
|
2001-12-02 13:34:01 +01:00
|
|
|
SLAVE { Lex->type|= REFRESH_SLAVE; }
|
|
|
|
| MASTER_SYM { Lex->type|= REFRESH_MASTER; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| QUERY_SYM CACHE_SYM { Lex->type|= REFRESH_QUERY_CACHE;};
|
2000-10-14 10:16:17 +02:00
|
|
|
|
2000-10-27 06:11:55 +02:00
|
|
|
purge:
|
2001-06-15 04:03:15 +02:00
|
|
|
PURGE
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->type=0;
|
2007-06-06 15:29:15 +02:00
|
|
|
lex->sql_command = SQLCOM_PURGE;
|
2003-02-16 17:39:12 +01:00
|
|
|
} purge_options
|
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
|
|
|
purge_options:
|
2003-07-12 23:31:21 +02:00
|
|
|
master_or_binary LOGS_SYM purge_option
|
2003-03-11 10:49:06 +01:00
|
|
|
;
|
2003-02-16 17:39:12 +01:00
|
|
|
|
|
|
|
purge_option:
|
2003-03-17 18:56:34 +01:00
|
|
|
TO_SYM TEXT_STRING_sys
|
2003-02-16 17:39:12 +01:00
|
|
|
{
|
|
|
|
Lex->to_log = $2.str;
|
|
|
|
}
|
|
|
|
| BEFORE_SYM expr
|
|
|
|
{
|
2004-11-25 16:13:06 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->value_list.empty();
|
|
|
|
lex->value_list.push_front($2);
|
|
|
|
lex->sql_command= SQLCOM_PURGE_BEFORE;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2003-03-11 10:49:06 +01:00
|
|
|
;
|
2000-10-27 06:11:55 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/* kill threads */
|
|
|
|
|
|
|
|
kill:
|
2006-11-02 13:51:43 +01:00
|
|
|
KILL_SYM kill_option expr
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
2004-11-25 16:13:06 +01:00
|
|
|
lex->value_list.empty();
|
2006-11-02 13:51:43 +01:00
|
|
|
lex->value_list.push_front($3);
|
|
|
|
lex->sql_command= SQLCOM_KILL;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
kill_option:
|
|
|
|
/* empty */ { Lex->type= 0; }
|
|
|
|
| CONNECTION_SYM { Lex->type= 0; }
|
2006-03-06 20:53:14 +01:00
|
|
|
| QUERY_SYM { Lex->type= ONLY_KILL_QUERY; }
|
|
|
|
;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/* change database */
|
|
|
|
|
|
|
|
use: USE_SYM ident
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2002-10-30 12:18:52 +01:00
|
|
|
lex->sql_command=SQLCOM_CHANGE_DB;
|
|
|
|
lex->select_lex.db= $2.str;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
/* import, export of files */
|
|
|
|
|
2006-03-06 20:53:14 +01:00
|
|
|
load: LOAD DATA_SYM
|
2005-03-16 02:32:47 +01:00
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
|
|
|
|
2005-05-20 17:47:08 +02:00
|
|
|
if (lex->sphead)
|
|
|
|
{
|
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "LOAD DATA");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-05-20 17:47:08 +02:00
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
lex->fname_start= lip->get_ptr();
|
2005-03-16 02:32:47 +01:00
|
|
|
}
|
|
|
|
load_data
|
|
|
|
{}
|
|
|
|
|
|
|
|
|
LOAD TABLE_SYM table_ident FROM MASTER_SYM
|
|
|
|
{
|
2005-05-20 17:47:08 +02:00
|
|
|
LEX *lex=Lex;
|
2006-03-01 21:36:05 +01:00
|
|
|
WARN_DEPRECATED(yythd, "5.2", "LOAD TABLE FROM MASTER",
|
|
|
|
"MySQL Administrator (mysqldump, mysql)");
|
2006-02-19 18:41:59 +01:00
|
|
|
if (lex->sphead)
|
2005-05-20 17:47:08 +02:00
|
|
|
{
|
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "LOAD TABLE");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-05-20 17:47:08 +02:00
|
|
|
}
|
|
|
|
lex->sql_command = SQLCOM_LOAD_MASTER_TABLE;
|
2005-03-16 02:32:47 +01:00
|
|
|
if (!Select->add_table_to_list(YYTHD, $3, NULL, TL_OPTION_UPDATING))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-03-16 02:32:47 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
load_data:
|
2006-01-18 09:55:38 +01:00
|
|
|
load_data_lock opt_local INFILE TEXT_STRING_filesystem
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_LOAD;
|
2005-03-16 02:32:47 +01:00
|
|
|
lex->lock_option= $1;
|
|
|
|
lex->local_file= $2;
|
2004-12-31 11:04:35 +01:00
|
|
|
lex->duplicates= DUP_ERROR;
|
|
|
|
lex->ignore= 0;
|
2005-03-16 02:32:47 +01:00
|
|
|
if (!(lex->exchange= new sql_exchange($4.str, 0)))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-03-16 02:32:47 +01:00
|
|
|
}
|
|
|
|
opt_duplicate INTO
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
lex->fname_end= lip->get_ptr();
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2005-03-16 10:13:35 +01:00
|
|
|
TABLE_SYM table_ident
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2005-03-16 10:13:35 +01:00
|
|
|
LEX *lex=Lex;
|
|
|
|
if (!Select->add_table_to_list(YYTHD, $10, NULL, TL_OPTION_UPDATING,
|
|
|
|
lex->lock_option))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-03-16 10:13:35 +01:00
|
|
|
lex->field_list.empty();
|
|
|
|
lex->update_list.empty();
|
|
|
|
lex->value_list.empty();
|
2000-08-21 23:39:08 +02:00
|
|
|
}
|
2007-02-28 14:06:57 +01:00
|
|
|
opt_load_data_charset
|
|
|
|
{ Lex->exchange->cs= $12; }
|
2005-03-16 10:13:35 +01:00
|
|
|
opt_field_term opt_line_term opt_ignore_lines opt_field_or_var_spec
|
|
|
|
opt_load_data_set_spec
|
|
|
|
{}
|
2001-05-29 03:18:23 +02:00
|
|
|
|
|
2005-03-16 02:32:47 +01:00
|
|
|
FROM MASTER_SYM
|
2001-05-29 03:18:23 +02:00
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_LOAD_MASTER_DATA;
|
2006-09-11 19:45:09 +02:00
|
|
|
WARN_DEPRECATED(yythd, "5.2", "LOAD DATA FROM MASTER",
|
2006-09-11 13:50:41 +02:00
|
|
|
"mysqldump or future "
|
|
|
|
"BACKUP/RESTORE DATABASE facility");
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_local:
|
|
|
|
/* empty */ { $$=0;}
|
2002-04-16 01:09:30 +02:00
|
|
|
| LOCAL_SYM { $$=1;};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-05-05 08:41:47 +02:00
|
|
|
load_data_lock:
|
2007-06-03 08:40:00 +02:00
|
|
|
/* empty */ { $$= TL_WRITE_DEFAULT; }
|
2006-03-15 18:15:52 +01:00
|
|
|
| CONCURRENT
|
|
|
|
{
|
|
|
|
#ifdef HAVE_QUERY_CACHE
|
|
|
|
/*
|
|
|
|
Ignore this option in SP to avoid problem with query cache
|
|
|
|
*/
|
|
|
|
if (Lex->sphead != 0)
|
2007-06-03 08:40:00 +02:00
|
|
|
$$= TL_WRITE_DEFAULT;
|
2006-11-29 13:51:53 +01:00
|
|
|
else
|
2006-03-15 18:15:52 +01:00
|
|
|
#endif
|
|
|
|
$$= TL_WRITE_CONCURRENT_INSERT;
|
|
|
|
}
|
2002-11-16 19:19:10 +01:00
|
|
|
| LOW_PRIORITY { $$= TL_WRITE_LOW_PRIORITY; };
|
2001-05-05 08:41:47 +02:00
|
|
|
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
opt_duplicate:
|
|
|
|
/* empty */ { Lex->duplicates=DUP_ERROR; }
|
|
|
|
| REPLACE { Lex->duplicates=DUP_REPLACE; }
|
2004-12-31 11:04:35 +01:00
|
|
|
| IGNORE_SYM { Lex->ignore= 1; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_field_term:
|
|
|
|
/* empty */
|
2002-04-16 01:09:30 +02:00
|
|
|
| COLUMNS field_term_list;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
field_term_list:
|
|
|
|
field_term_list field_term
|
2002-04-16 01:09:30 +02:00
|
|
|
| field_term;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
field_term:
|
2004-10-10 11:40:24 +02:00
|
|
|
TERMINATED BY text_string
|
|
|
|
{
|
2005-02-25 15:53:22 +01:00
|
|
|
DBUG_ASSERT(Lex->exchange != 0);
|
2004-10-10 11:40:24 +02:00
|
|
|
Lex->exchange->field_term= $3;
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| OPTIONALLY ENCLOSED BY text_string
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2004-10-10 12:29:06 +02:00
|
|
|
LEX *lex= Lex;
|
2005-02-25 15:53:22 +01:00
|
|
|
DBUG_ASSERT(lex->exchange != 0);
|
2004-10-10 12:29:06 +02:00
|
|
|
lex->exchange->enclosed= $4;
|
|
|
|
lex->exchange->opt_enclosed= 1;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2004-10-10 12:29:06 +02:00
|
|
|
| ENCLOSED BY text_string
|
2004-10-10 11:40:24 +02:00
|
|
|
{
|
2005-02-25 15:53:22 +01:00
|
|
|
DBUG_ASSERT(Lex->exchange != 0);
|
2004-10-10 11:40:24 +02:00
|
|
|
Lex->exchange->enclosed= $3;
|
|
|
|
}
|
2004-10-10 12:29:06 +02:00
|
|
|
| ESCAPED BY text_string
|
2004-10-10 11:40:24 +02:00
|
|
|
{
|
2005-02-25 15:53:22 +01:00
|
|
|
DBUG_ASSERT(Lex->exchange != 0);
|
2004-10-10 11:40:24 +02:00
|
|
|
Lex->exchange->escaped= $3;
|
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_line_term:
|
|
|
|
/* empty */
|
2002-04-16 01:09:30 +02:00
|
|
|
| LINES line_term_list;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
line_term_list:
|
|
|
|
line_term_list line_term
|
2002-04-16 01:09:30 +02:00
|
|
|
| line_term;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
line_term:
|
2004-10-10 12:29:06 +02:00
|
|
|
TERMINATED BY text_string
|
2004-10-10 11:40:24 +02:00
|
|
|
{
|
2005-02-25 15:53:22 +01:00
|
|
|
DBUG_ASSERT(Lex->exchange != 0);
|
2004-10-10 11:40:24 +02:00
|
|
|
Lex->exchange->line_term= $3;
|
|
|
|
}
|
2004-10-10 12:29:06 +02:00
|
|
|
| STARTING BY text_string
|
2004-10-10 11:40:24 +02:00
|
|
|
{
|
2005-02-25 15:53:22 +01:00
|
|
|
DBUG_ASSERT(Lex->exchange != 0);
|
2004-10-10 11:40:24 +02:00
|
|
|
Lex->exchange->line_start= $3;
|
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_ignore_lines:
|
|
|
|
/* empty */
|
2004-10-10 12:29:06 +02:00
|
|
|
| IGNORE_SYM NUM LINES
|
|
|
|
{
|
2005-02-25 15:53:22 +01:00
|
|
|
DBUG_ASSERT(Lex->exchange != 0);
|
2004-10-10 11:40:24 +02:00
|
|
|
Lex->exchange->skip_lines= atol($2.str);
|
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-03-16 02:32:47 +01:00
|
|
|
opt_field_or_var_spec:
|
|
|
|
/* empty */ { }
|
|
|
|
| '(' fields_or_vars ')' { }
|
|
|
|
| '(' ')' { };
|
|
|
|
|
|
|
|
fields_or_vars:
|
|
|
|
fields_or_vars ',' field_or_var
|
|
|
|
{ Lex->field_list.push_back($3); }
|
|
|
|
| field_or_var
|
|
|
|
{ Lex->field_list.push_back($1); }
|
|
|
|
;
|
2005-04-04 00:50:05 +02:00
|
|
|
|
2005-03-16 02:32:47 +01:00
|
|
|
field_or_var:
|
|
|
|
simple_ident_nospvar {$$= $1;}
|
|
|
|
| '@' ident_or_text
|
|
|
|
{ $$= new Item_user_var_as_out_param($2); }
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_load_data_set_spec:
|
|
|
|
/* empty */ { }
|
|
|
|
| SET insert_update_list { };
|
|
|
|
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/* Common definitions */
|
|
|
|
|
|
|
|
text_literal:
|
2003-04-08 11:38:17 +02:00
|
|
|
TEXT_STRING_literal
|
2003-03-17 18:56:34 +01:00
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
2003-04-23 15:19:22 +02:00
|
|
|
$$ = new Item_string($1.str,$1.length,thd->variables.collation_connection);
|
2003-03-17 18:56:34 +01:00
|
|
|
}
|
2003-03-20 19:01:03 +01:00
|
|
|
| NCHAR_STRING
|
2003-03-21 08:21:01 +01:00
|
|
|
{ $$= new Item_string($1.str,$1.length,national_charset_info); }
|
2003-02-12 20:55:37 +01:00
|
|
|
| UNDERSCORE_CHARSET TEXT_STRING
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
{
|
|
|
|
$$ = new Item_string($2.str, $2.length, $1);
|
|
|
|
}
|
2003-04-08 11:38:17 +02:00
|
|
|
| text_literal TEXT_STRING_literal
|
2003-03-20 19:01:03 +01:00
|
|
|
{ ((Item_string*) $1)->append($2.str,$2.length); }
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
text_string:
|
2003-04-08 11:38:17 +02:00
|
|
|
TEXT_STRING_literal
|
2004-11-08 00:13:54 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) String($1.str,$1.length,YYTHD->variables.collation_connection); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| HEX_NUM
|
|
|
|
{
|
2004-12-17 15:06:05 +01:00
|
|
|
Item *tmp= new Item_hex_string($1.str, $1.length);
|
2004-03-18 14:14:36 +01:00
|
|
|
/*
|
2004-12-17 15:06:05 +01:00
|
|
|
it is OK only emulate fix_fields, because we need only
|
2004-03-18 14:14:36 +01:00
|
|
|
value of constant
|
|
|
|
*/
|
|
|
|
$$= tmp ?
|
2004-03-20 12:36:26 +01:00
|
|
|
tmp->quick_fix_field(), tmp->val_str((String*) 0) :
|
2004-03-18 14:14:36 +01:00
|
|
|
(String*) 0;
|
2003-02-12 20:55:37 +01:00
|
|
|
}
|
2004-12-17 15:06:05 +01:00
|
|
|
| BIN_NUM
|
|
|
|
{
|
|
|
|
Item *tmp= new Item_bin_string($1.str, $1.length);
|
|
|
|
/*
|
|
|
|
it is OK only emulate fix_fields, because we need only
|
|
|
|
value of constant
|
|
|
|
*/
|
|
|
|
$$= tmp ? tmp->quick_fix_field(), tmp->val_str((String*) 0) :
|
|
|
|
(String*) 0;
|
|
|
|
}
|
2003-02-12 20:55:37 +01:00
|
|
|
;
|
|
|
|
|
2002-06-12 23:13:12 +02:00
|
|
|
param_marker:
|
2005-07-14 22:01:49 +02:00
|
|
|
PARAM_MARKER
|
2002-06-12 23:13:12 +02:00
|
|
|
{
|
2007-01-27 02:46:45 +01:00
|
|
|
THD *thd= YYTHD;
|
2007-04-26 05:38:12 +02:00
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2006-10-12 16:02:57 +02:00
|
|
|
Item_param *item;
|
|
|
|
if (! lex->parsing_options.allows_variable)
|
|
|
|
{
|
|
|
|
my_error(ER_VIEW_SELECT_VARIABLE, MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-10-12 16:02:57 +02:00
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
item= new Item_param((uint) (lip->get_tok_start() - thd->query));
|
2005-07-14 22:01:49 +02:00
|
|
|
if (!($$= item) || lex->param_list.push_back(item))
|
2002-06-12 23:13:12 +02:00
|
|
|
{
|
2005-07-14 22:31:09 +02:00
|
|
|
my_message(ER_OUT_OF_RESOURCES, ER(ER_OUT_OF_RESOURCES), MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-06-12 23:13:12 +02:00
|
|
|
}
|
2003-02-12 20:55:37 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2003-12-11 17:05:51 +01:00
|
|
|
signed_literal:
|
|
|
|
literal { $$ = $1; }
|
|
|
|
| '+' NUM_literal { $$ = $2; }
|
2004-03-18 14:14:36 +01:00
|
|
|
| '-' NUM_literal
|
|
|
|
{
|
2004-03-18 17:27:03 +01:00
|
|
|
$2->max_length++;
|
2004-03-20 12:36:26 +01:00
|
|
|
$$= $2->neg();
|
2004-03-18 14:14:36 +01:00
|
|
|
}
|
2003-12-11 17:05:51 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
literal:
|
|
|
|
text_literal { $$ = $1; }
|
2003-12-11 17:05:51 +01:00
|
|
|
| NUM_literal { $$ = $1; }
|
2007-04-26 05:38:12 +02:00
|
|
|
| NULL_SYM
|
|
|
|
{
|
|
|
|
$$ = new Item_null();
|
|
|
|
YYTHD->m_lip->next_state=MY_LEX_OPERATOR_OR_IDENT;
|
|
|
|
}
|
2005-05-07 14:51:29 +02:00
|
|
|
| FALSE_SYM { $$= new Item_int((char*) "FALSE",0,1); }
|
|
|
|
| TRUE_SYM { $$= new Item_int((char*) "TRUE",1,1); }
|
2004-12-17 15:06:05 +01:00
|
|
|
| HEX_NUM { $$ = new Item_hex_string($1.str, $1.length);}
|
|
|
|
| BIN_NUM { $$= new Item_bin_string($1.str, $1.length); }
|
2003-03-20 16:11:15 +01:00
|
|
|
| UNDERSCORE_CHARSET HEX_NUM
|
2003-07-20 12:26:18 +02:00
|
|
|
{
|
2004-12-17 15:06:05 +01:00
|
|
|
Item *tmp= new Item_hex_string($2.str, $2.length);
|
2004-03-18 14:14:36 +01:00
|
|
|
/*
|
2004-03-20 12:36:26 +01:00
|
|
|
it is OK only emulate fix_fieds, because we need only
|
2004-03-18 14:14:36 +01:00
|
|
|
value of constant
|
|
|
|
*/
|
|
|
|
String *str= tmp ?
|
2004-03-20 12:36:26 +01:00
|
|
|
tmp->quick_fix_field(), tmp->val_str((String*) 0) :
|
2004-03-18 14:14:36 +01:00
|
|
|
(String*) 0;
|
2003-10-16 14:54:47 +02:00
|
|
|
$$= new Item_string(str ? str->ptr() : "",
|
|
|
|
str ? str->length() : 0,
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
$1);
|
2003-03-20 16:11:15 +01:00
|
|
|
}
|
2004-12-17 15:06:05 +01:00
|
|
|
| UNDERSCORE_CHARSET BIN_NUM
|
|
|
|
{
|
|
|
|
Item *tmp= new Item_bin_string($2.str, $2.length);
|
|
|
|
/*
|
|
|
|
it is OK only emulate fix_fieds, because we need only
|
|
|
|
value of constant
|
|
|
|
*/
|
|
|
|
String *str= tmp ?
|
|
|
|
tmp->quick_fix_field(), tmp->val_str((String*) 0) :
|
|
|
|
(String*) 0;
|
|
|
|
$$= new Item_string(str ? str->ptr() : "",
|
|
|
|
str ? str->length() : 0,
|
|
|
|
Lex->charset);
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| DATE_SYM text_literal { $$ = $2; }
|
|
|
|
| TIME_SYM text_literal { $$ = $2; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| TIMESTAMP text_literal { $$ = $2; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-12-11 01:28:25 +01:00
|
|
|
NUM_literal:
|
2004-05-14 19:12:09 +02:00
|
|
|
NUM { int error; $$ = new Item_int($1.str, (longlong) my_strtoll10($1.str, NULL, &error), $1.length); }
|
|
|
|
| LONG_NUM { int error; $$ = new Item_int($1.str, (longlong) my_strtoll10($1.str, NULL, &error), $1.length); }
|
2003-12-11 01:28:25 +01:00
|
|
|
| ULONGLONG_NUM { $$ = new Item_uint($1.str, $1.length); }
|
2005-02-08 23:50:45 +01:00
|
|
|
| DECIMAL_NUM
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2005-02-08 23:50:45 +01:00
|
|
|
$$= new Item_decimal($1.str, $1.length, YYTHD->charset());
|
2004-11-12 04:01:46 +01:00
|
|
|
if (YYTHD->net.report_error)
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
| FLOAT_NUM
|
|
|
|
{
|
|
|
|
$$ = new Item_float($1.str, $1.length);
|
|
|
|
if (YYTHD->net.report_error)
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
}
|
2003-12-11 01:28:25 +01:00
|
|
|
;
|
2005-04-04 00:50:05 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/**********************************************************************
|
2005-04-04 00:50:05 +02:00
|
|
|
** Creating different items.
|
2000-07-31 21:29:14 +02:00
|
|
|
**********************************************************************/
|
|
|
|
|
|
|
|
insert_ident:
|
2004-11-12 04:01:46 +01:00
|
|
|
simple_ident_nospvar { $$=$1; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| table_wild { $$=$1; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
table_wild:
|
2003-08-11 21:44:43 +02:00
|
|
|
ident '.' '*'
|
2003-01-25 01:25:52 +01:00
|
|
|
{
|
2005-07-01 06:05:42 +02:00
|
|
|
SELECT_LEX *sel= Select;
|
2005-08-12 16:57:19 +02:00
|
|
|
$$ = new Item_field(Lex->current_context(), NullS, $1.str, "*");
|
2005-07-01 06:05:42 +02:00
|
|
|
sel->with_wild++;
|
2003-01-25 01:25:52 +01:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| ident '.' ident '.' '*'
|
2003-01-25 01:25:52 +01:00
|
|
|
{
|
2005-07-01 06:05:42 +02:00
|
|
|
SELECT_LEX *sel= Select;
|
2005-08-12 16:57:19 +02:00
|
|
|
$$ = new Item_field(Lex->current_context(), (YYTHD->client_capabilities &
|
2005-04-04 00:50:05 +02:00
|
|
|
CLIENT_NO_SCHEMA ? NullS : $1.str),
|
|
|
|
$3.str,"*");
|
2005-07-01 06:05:42 +02:00
|
|
|
sel->with_wild++;
|
2003-01-25 01:25:52 +01:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
order_ident:
|
2002-04-16 01:09:30 +02:00
|
|
|
expr { $$=$1; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
simple_ident:
|
2004-11-12 04:01:46 +01:00
|
|
|
ident
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2006-04-07 16:53:15 +02:00
|
|
|
sp_variable_t *spv;
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_pcontext *spc = lex->spcont;
|
2006-04-07 16:53:15 +02:00
|
|
|
if (spc && (spv = spc->find_variable(&$1)))
|
2005-08-25 15:34:34 +02:00
|
|
|
{
|
|
|
|
/* We're compiling a stored procedure and found a variable */
|
2006-10-12 16:02:57 +02:00
|
|
|
if (! lex->parsing_options.allows_variable)
|
|
|
|
{
|
|
|
|
my_error(ER_VIEW_SELECT_VARIABLE, MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-10-12 16:02:57 +02:00
|
|
|
}
|
|
|
|
|
2005-08-25 15:34:34 +02:00
|
|
|
Item_splocal *splocal;
|
2005-12-07 15:01:17 +01:00
|
|
|
splocal= new Item_splocal($1, spv->offset, spv->type,
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
lip->get_tok_start_prev() -
|
2005-08-25 15:34:34 +02:00
|
|
|
lex->sphead->m_tmp_query);
|
2005-11-23 11:26:07 +01:00
|
|
|
#ifndef DBUG_OFF
|
2005-11-22 23:50:37 +01:00
|
|
|
if (splocal)
|
2005-12-07 15:01:17 +01:00
|
|
|
splocal->m_sp= lex->sphead;
|
2005-11-22 23:50:37 +01:00
|
|
|
#endif
|
2005-08-25 15:34:34 +02:00
|
|
|
$$ = (Item*) splocal;
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->safe_to_cache_query=0;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
SELECT_LEX *sel=Select;
|
|
|
|
$$= (sel->parsing_place != IN_HAVING ||
|
|
|
|
sel->get_in_sum_expr() > 0) ?
|
2005-08-12 16:57:19 +02:00
|
|
|
(Item*) new Item_field(Lex->current_context(), NullS, NullS, $1.str) :
|
|
|
|
(Item*) new Item_ref(Lex->current_context(), NullS, NullS, $1.str);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
| simple_ident_q { $$= $1; }
|
|
|
|
;
|
|
|
|
|
|
|
|
simple_ident_nospvar:
|
2000-07-31 21:29:14 +02:00
|
|
|
ident
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel=Select;
|
2004-08-13 09:01:30 +02:00
|
|
|
$$= (sel->parsing_place != IN_HAVING ||
|
2003-05-17 09:05:07 +02:00
|
|
|
sel->get_in_sum_expr() > 0) ?
|
2005-08-12 16:57:19 +02:00
|
|
|
(Item*) new Item_field(Lex->current_context(), NullS, NullS, $1.str) :
|
|
|
|
(Item*) new Item_ref(Lex->current_context(), NullS, NullS, $1.str);
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
| simple_ident_q { $$= $1; }
|
2005-04-04 00:50:05 +02:00
|
|
|
;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
|
|
|
simple_ident_q:
|
|
|
|
ident '.' ident
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2003-01-14 17:00:34 +01:00
|
|
|
THD *thd= YYTHD;
|
2003-12-19 18:52:13 +01:00
|
|
|
LEX *lex= thd->lex;
|
2005-04-04 00:50:05 +02:00
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
/*
|
|
|
|
FIXME This will work ok in simple_ident_nospvar case because
|
|
|
|
we can't meet simple_ident_nospvar in trigger now. But it
|
|
|
|
should be changed in future.
|
|
|
|
*/
|
|
|
|
if (lex->sphead && lex->sphead->m_type == TYPE_ENUM_TRIGGER &&
|
2005-04-04 00:50:05 +02:00
|
|
|
(!my_strcasecmp(system_charset_info, $1.str, "NEW") ||
|
2004-11-12 04:01:46 +01:00
|
|
|
!my_strcasecmp(system_charset_info, $1.str, "OLD")))
|
|
|
|
{
|
2004-11-24 10:24:02 +01:00
|
|
|
Item_trigger_field *trg_fld;
|
2004-11-12 04:01:46 +01:00
|
|
|
bool new_row= ($1.str[0]=='N' || $1.str[0]=='n');
|
2005-04-04 00:50:05 +02:00
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
if (lex->trg_chistics.event == TRG_EVENT_INSERT &&
|
|
|
|
!new_row)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_TRG_NO_SUCH_ROW_IN_TRG, MYF(0), "OLD", "on INSERT");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2005-04-04 00:50:05 +02:00
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
if (lex->trg_chistics.event == TRG_EVENT_DELETE &&
|
|
|
|
new_row)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_TRG_NO_SUCH_ROW_IN_TRG, MYF(0), "NEW", "on DELETE");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2005-04-04 00:50:05 +02:00
|
|
|
|
2006-05-12 11:55:21 +02:00
|
|
|
DBUG_ASSERT(!new_row ||
|
|
|
|
(lex->trg_chistics.event == TRG_EVENT_INSERT ||
|
|
|
|
lex->trg_chistics.event == TRG_EVENT_UPDATE));
|
|
|
|
const bool read_only=
|
|
|
|
!(new_row && lex->trg_chistics.action_time == TRG_ACTION_BEFORE);
|
2005-08-12 16:57:19 +02:00
|
|
|
if (!(trg_fld= new Item_trigger_field(Lex->current_context(),
|
2005-07-01 06:05:42 +02:00
|
|
|
new_row ?
|
2004-11-24 10:24:02 +01:00
|
|
|
Item_trigger_field::NEW_ROW:
|
|
|
|
Item_trigger_field::OLD_ROW,
|
2006-01-24 18:15:12 +01:00
|
|
|
$3.str,
|
2006-05-12 11:55:21 +02:00
|
|
|
SELECT_ACL,
|
|
|
|
read_only)))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-04-04 00:50:05 +02:00
|
|
|
|
2004-11-24 10:24:02 +01:00
|
|
|
/*
|
|
|
|
Let us add this item to list of all Item_trigger_field objects
|
|
|
|
in trigger.
|
|
|
|
*/
|
WL#3817: Simplify string / memory area types and make things more consistent (first part)
The following type conversions was done:
- Changed byte to uchar
- Changed gptr to uchar*
- Change my_string to char *
- Change my_size_t to size_t
- Change size_s to size_t
Removed declaration of byte, gptr, my_string, my_size_t and size_s.
Following function parameter changes was done:
- All string functions in mysys/strings was changed to use size_t
instead of uint for string lengths.
- All read()/write() functions changed to use size_t (including vio).
- All protocoll functions changed to use size_t instead of uint
- Functions that used a pointer to a string length was changed to use size_t*
- Changed malloc(), free() and related functions from using gptr to use void *
as this requires fewer casts in the code and is more in line with how the
standard functions work.
- Added extra length argument to dirname_part() to return the length of the
created string.
- Changed (at least) following functions to take uchar* as argument:
- db_dump()
- my_net_write()
- net_write_command()
- net_store_data()
- DBUG_DUMP()
- decimal2bin() & bin2decimal()
- Changed my_compress() and my_uncompress() to use size_t. Changed one
argument to my_uncompress() from a pointer to a value as we only return
one value (makes function easier to use).
- Changed type of 'pack_data' argument to packfrm() to avoid casts.
- Changed in readfrm() and writefrom(), ha_discover and handler::discover()
the type for argument 'frmdata' to uchar** to avoid casts.
- Changed most Field functions to use uchar* instead of char* (reduced a lot of
casts).
- Changed field->val_xxx(xxx, new_ptr) to take const pointers.
Other changes:
- Removed a lot of not needed casts
- Added a few new cast required by other changes
- Added some cast to my_multi_malloc() arguments for safety (as string lengths
needs to be uint, not size_t).
- Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
explicitely as this conflict was often hided by casting the function to
hash_get_key).
- Changed some buffers to memory regions to uchar* to avoid casts.
- Changed some string lengths from uint to size_t.
- Changed field->ptr to be uchar* instead of char*. This allowed us to
get rid of a lot of casts.
- Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
- Include zlib.h in some files as we needed declaration of crc32()
- Changed MY_FILE_ERROR to be (size_t) -1.
- Changed many variables to hold the result of my_read() / my_write() to be
size_t. This was needed to properly detect errors (which are
returned as (size_t) -1).
- Removed some very old VMS code
- Changed packfrm()/unpackfrm() to not be depending on uint size
(portability fix)
- Removed windows specific code to restore cursor position as this
causes slowdown on windows and we should not mix read() and pread()
calls anyway as this is not thread safe. Updated function comment to
reflect this. Changed function that depended on original behavior of
my_pwrite() to itself restore the cursor position (one such case).
- Added some missing checking of return value of malloc().
- Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
- Changed type of table_def::m_size from my_size_t to ulong to reflect that
m_size is the number of elements in the array, not a string/memory
length.
- Moved THD::max_row_length() to table.cc (as it's not depending on THD).
Inlined max_row_length_blob() into this function.
- More function comments
- Fixed some compiler warnings when compiled without partitions.
- Removed setting of LEX_STRING() arguments in declaration (portability fix).
- Some trivial indentation/variable name changes.
- Some trivial code simplifications:
- Replaced some calls to alloc_root + memcpy to use
strmake_root()/strdup_root().
- Changed some calls from memdup() to strmake() (Safety fix)
- Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
|
|
|
lex->trg_table_fields.link_in_list((uchar*) trg_fld,
|
|
|
|
(uchar**) &trg_fld->
|
|
|
|
next_trg_field);
|
2005-04-04 00:50:05 +02:00
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
$$= (Item *)trg_fld;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
SELECT_LEX *sel= lex->current_select;
|
|
|
|
if (sel->no_table_names_allowed)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_TABLENAME_NOT_ALLOWED_HERE,
|
|
|
|
MYF(0), $1.str, thd->where);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
$$= (sel->parsing_place != IN_HAVING ||
|
|
|
|
sel->get_in_sum_expr() > 0) ?
|
2005-08-12 16:57:19 +02:00
|
|
|
(Item*) new Item_field(Lex->current_context(), NullS, $1.str, $3.str) :
|
|
|
|
(Item*) new Item_ref(Lex->current_context(), NullS, $1.str, $3.str);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| '.' ident '.' ident
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2003-01-14 17:00:34 +01:00
|
|
|
THD *thd= YYTHD;
|
2003-12-19 18:52:13 +01:00
|
|
|
LEX *lex= thd->lex;
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel= lex->current_select;
|
2003-01-14 17:00:34 +01:00
|
|
|
if (sel->no_table_names_allowed)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_TABLENAME_NOT_ALLOWED_HERE,
|
|
|
|
MYF(0), $2.str, thd->where);
|
2003-01-14 17:00:34 +01:00
|
|
|
}
|
2004-08-13 09:01:30 +02:00
|
|
|
$$= (sel->parsing_place != IN_HAVING ||
|
2003-05-17 09:05:07 +02:00
|
|
|
sel->get_in_sum_expr() > 0) ?
|
2005-08-12 16:57:19 +02:00
|
|
|
(Item*) new Item_field(Lex->current_context(), NullS, $2.str, $4.str) :
|
|
|
|
(Item*) new Item_ref(Lex->current_context(), NullS, $2.str, $4.str);
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| ident '.' ident '.' ident
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2003-01-14 17:00:34 +01:00
|
|
|
THD *thd= YYTHD;
|
2003-12-19 18:52:13 +01:00
|
|
|
LEX *lex= thd->lex;
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel= lex->current_select;
|
2003-01-14 17:00:34 +01:00
|
|
|
if (sel->no_table_names_allowed)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_TABLENAME_NOT_ALLOWED_HERE,
|
|
|
|
MYF(0), $3.str, thd->where);
|
2003-01-14 17:00:34 +01:00
|
|
|
}
|
2004-08-13 09:01:30 +02:00
|
|
|
$$= (sel->parsing_place != IN_HAVING ||
|
2003-05-17 09:05:07 +02:00
|
|
|
sel->get_in_sum_expr() > 0) ?
|
2005-08-12 16:57:19 +02:00
|
|
|
(Item*) new Item_field(Lex->current_context(),
|
2005-07-01 06:05:42 +02:00
|
|
|
(YYTHD->client_capabilities &
|
2003-05-17 09:05:07 +02:00
|
|
|
CLIENT_NO_SCHEMA ? NullS : $1.str),
|
|
|
|
$3.str, $5.str) :
|
2005-08-12 16:57:19 +02:00
|
|
|
(Item*) new Item_ref(Lex->current_context(),
|
2005-07-01 06:05:42 +02:00
|
|
|
(YYTHD->client_capabilities &
|
2004-10-08 17:13:09 +02:00
|
|
|
CLIENT_NO_SCHEMA ? NullS : $1.str),
|
2003-05-17 09:05:07 +02:00
|
|
|
$3.str, $5.str);
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
field_ident:
|
|
|
|
ident { $$=$1;}
|
2005-05-31 19:06:54 +02:00
|
|
|
| ident '.' ident '.' ident
|
|
|
|
{
|
|
|
|
TABLE_LIST *table= (TABLE_LIST*) Select->table_list.first;
|
|
|
|
if (my_strcasecmp(table_alias_charset, $1.str, table->db))
|
|
|
|
{
|
2005-06-01 13:22:17 +02:00
|
|
|
my_error(ER_WRONG_DB_NAME, MYF(0), $1.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-05-31 19:06:54 +02:00
|
|
|
}
|
2005-06-01 13:22:17 +02:00
|
|
|
if (my_strcasecmp(table_alias_charset, $3.str,
|
|
|
|
table->table_name))
|
2005-05-31 19:06:54 +02:00
|
|
|
{
|
2005-06-01 13:22:17 +02:00
|
|
|
my_error(ER_WRONG_TABLE_NAME, MYF(0), $3.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-05-31 19:06:54 +02:00
|
|
|
}
|
|
|
|
$$=$5;
|
|
|
|
}
|
|
|
|
| ident '.' ident
|
|
|
|
{
|
|
|
|
TABLE_LIST *table= (TABLE_LIST*) Select->table_list.first;
|
|
|
|
if (my_strcasecmp(table_alias_charset, $1.str, table->alias))
|
|
|
|
{
|
2005-06-01 13:22:17 +02:00
|
|
|
my_error(ER_WRONG_TABLE_NAME, MYF(0), $1.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-05-31 19:06:54 +02:00
|
|
|
}
|
|
|
|
$$=$3;
|
|
|
|
}
|
2002-04-16 01:09:30 +02:00
|
|
|
| '.' ident { $$=$2;} /* For Delphi */;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
table_ident:
|
|
|
|
ident { $$=new Table_ident($1); }
|
2003-03-17 14:05:04 +01:00
|
|
|
| ident '.' ident { $$=new Table_ident(YYTHD, $1,$3,0);}
|
2004-01-13 12:31:25 +01:00
|
|
|
| '.' ident { $$=new Table_ident($2);} /* For Delphi */
|
|
|
|
;
|
|
|
|
|
2004-06-26 14:21:32 +02:00
|
|
|
table_ident_nodb:
|
2004-02-16 09:03:25 +01:00
|
|
|
ident { LEX_STRING db={(char*) any_db,3}; $$=new Table_ident(YYTHD, db,$1,0); }
|
2004-01-13 12:31:25 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-03-17 18:56:34 +01:00
|
|
|
IDENT_sys:
|
2003-11-03 13:01:59 +01:00
|
|
|
IDENT { $$= $1; }
|
|
|
|
| IDENT_QUOTED
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
|
2003-11-03 13:01:59 +01:00
|
|
|
if (thd->charset_is_system_charset)
|
2004-07-07 13:39:43 +02:00
|
|
|
{
|
|
|
|
CHARSET_INFO *cs= system_charset_info;
|
2005-04-06 08:53:15 +02:00
|
|
|
int dummy_error;
|
2004-07-07 13:39:43 +02:00
|
|
|
uint wlen= cs->cset->well_formed_len(cs, $1.str,
|
|
|
|
$1.str+$1.length,
|
2005-04-06 08:53:15 +02:00
|
|
|
$1.length, &dummy_error);
|
2004-07-07 13:39:43 +02:00
|
|
|
if (wlen < $1.length)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_INVALID_CHARACTER_STRING, MYF(0),
|
|
|
|
cs->csname, $1.str + wlen);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-07-07 13:39:43 +02:00
|
|
|
}
|
2003-11-03 13:01:59 +01:00
|
|
|
$$= $1;
|
2004-07-07 13:39:43 +02:00
|
|
|
}
|
2003-11-03 13:01:59 +01:00
|
|
|
else
|
|
|
|
thd->convert_string(&$$, system_charset_info,
|
|
|
|
$1.str, $1.length, thd->charset());
|
|
|
|
}
|
2003-03-17 18:56:34 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
TEXT_STRING_sys:
|
|
|
|
TEXT_STRING
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
|
2003-08-18 23:08:08 +02:00
|
|
|
if (thd->charset_is_system_charset)
|
|
|
|
$$= $1;
|
2003-03-17 18:56:34 +01:00
|
|
|
else
|
2003-08-18 23:08:08 +02:00
|
|
|
thd->convert_string(&$$, system_charset_info,
|
|
|
|
$1.str, $1.length, thd->charset());
|
2003-03-17 18:56:34 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2003-04-08 11:38:17 +02:00
|
|
|
TEXT_STRING_literal:
|
2003-03-17 18:56:34 +01:00
|
|
|
TEXT_STRING
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
|
2003-08-18 23:08:08 +02:00
|
|
|
if (thd->charset_is_collation_connection)
|
|
|
|
$$= $1;
|
2003-03-17 18:56:34 +01:00
|
|
|
else
|
2003-08-18 23:08:08 +02:00
|
|
|
thd->convert_string(&$$, thd->variables.collation_connection,
|
|
|
|
$1.str, $1.length, thd->charset());
|
2003-03-17 18:56:34 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
|
2006-01-18 09:55:38 +01:00
|
|
|
TEXT_STRING_filesystem:
|
|
|
|
TEXT_STRING
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
|
2006-01-18 09:55:38 +01:00
|
|
|
if (thd->charset_is_character_set_filesystem)
|
|
|
|
$$= $1;
|
|
|
|
else
|
|
|
|
thd->convert_string(&$$, thd->variables.character_set_filesystem,
|
|
|
|
$1.str, $1.length, thd->charset());
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
ident:
|
2003-03-17 18:56:34 +01:00
|
|
|
IDENT_sys { $$=$1; }
|
2006-01-11 11:35:25 +01:00
|
|
|
| READ_ONLY_SYM
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
$$.str= thd->strmake("read_only",9);
|
|
|
|
$$.length= 9;
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| keyword
|
|
|
|
{
|
2003-08-18 23:08:08 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
$$.str= thd->strmake($1.str, $1.length);
|
|
|
|
$$.length= $1.length;
|
2002-11-20 21:56:57 +01:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-07-06 16:37:57 +02:00
|
|
|
label_ident:
|
|
|
|
IDENT_sys { $$=$1; }
|
|
|
|
| keyword_sp
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
$$.str= thd->strmake($1.str, $1.length);
|
|
|
|
$$.length= $1.length;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
ident_or_text:
|
2005-04-04 00:50:05 +02:00
|
|
|
ident { $$=$1;}
|
2003-03-17 18:56:34 +01:00
|
|
|
| TEXT_STRING_sys { $$=$1;}
|
|
|
|
| LEX_HOSTNAME { $$=$1;};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
user:
|
|
|
|
ident_or_text
|
|
|
|
{
|
2002-12-06 20:11:27 +01:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
if (!($$=(LEX_USER*) thd->alloc(sizeof(st_lex_user))))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-06-06 14:43:23 +02:00
|
|
|
$$->user = $1;
|
|
|
|
$$->host.str= (char *) "%";
|
|
|
|
$$->host.length= 1;
|
2006-08-23 19:31:00 +02:00
|
|
|
|
2007-04-03 13:13:27 +02:00
|
|
|
if (check_string_char_length(&$$->user, ER(ER_USERNAME),
|
|
|
|
USERNAME_CHAR_LENGTH,
|
|
|
|
system_charset_info, 0))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-06-06 14:43:23 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| ident_or_text '@' ident_or_text
|
|
|
|
{
|
2002-12-06 20:11:27 +01:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
if (!($$=(LEX_USER*) thd->alloc(sizeof(st_lex_user))))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
$$->user = $1; $$->host=$3;
|
2006-08-23 19:31:00 +02:00
|
|
|
|
2007-04-03 13:13:27 +02:00
|
|
|
if (check_string_char_length(&$$->user, ER(ER_USERNAME),
|
|
|
|
USERNAME_CHAR_LENGTH,
|
|
|
|
system_charset_info, 0) ||
|
|
|
|
check_string_byte_length(&$$->host, ER(ER_HOSTNAME),
|
|
|
|
HOSTNAME_LENGTH))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-04-05 14:55:26 +02:00
|
|
|
}
|
2004-04-06 12:00:51 +02:00
|
|
|
| CURRENT_USER optional_braces
|
2004-04-05 14:55:26 +02:00
|
|
|
{
|
2006-06-29 12:50:44 +02:00
|
|
|
if (!($$=(LEX_USER*) YYTHD->alloc(sizeof(st_lex_user))))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-06-29 12:50:44 +02:00
|
|
|
/*
|
|
|
|
empty LEX_USER means current_user and
|
|
|
|
will be handled in the get_current_user() function
|
|
|
|
later
|
|
|
|
*/
|
|
|
|
bzero($$, sizeof(LEX_USER));
|
2004-04-05 14:55:26 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-07-06 16:37:57 +02:00
|
|
|
/* Keyword that we allow for identifiers (except SP labels) */
|
2000-07-31 21:29:14 +02:00
|
|
|
keyword:
|
2005-07-06 16:37:57 +02:00
|
|
|
keyword_sp {}
|
|
|
|
| ASCII_SYM {}
|
|
|
|
| BACKUP_SYM {}
|
|
|
|
| BEGIN_SYM {}
|
|
|
|
| BYTE_SYM {}
|
|
|
|
| CACHE_SYM {}
|
|
|
|
| CHARSET {}
|
|
|
|
| CHECKSUM_SYM {}
|
|
|
|
| CLOSE_SYM {}
|
|
|
|
| COMMENT_SYM {}
|
|
|
|
| COMMIT_SYM {}
|
|
|
|
| CONTAINS_SYM {}
|
|
|
|
| DEALLOCATE_SYM {}
|
|
|
|
| DO_SYM {}
|
|
|
|
| END {}
|
|
|
|
| EXECUTE_SYM {}
|
|
|
|
| FLUSH_SYM {}
|
|
|
|
| HANDLER_SYM {}
|
|
|
|
| HELP_SYM {}
|
2006-12-02 01:47:45 +01:00
|
|
|
| HOST_SYM {}
|
2005-11-06 13:13:06 +01:00
|
|
|
| INSTALL_SYM {}
|
2005-07-06 16:37:57 +02:00
|
|
|
| LANGUAGE_SYM {}
|
|
|
|
| NO_SYM {}
|
|
|
|
| OPEN_SYM {}
|
2006-12-09 04:19:51 +01:00
|
|
|
| OPTIONS_SYM {}
|
2006-12-02 01:47:45 +01:00
|
|
|
| OWNER_SYM {}
|
2005-11-06 13:13:06 +01:00
|
|
|
| PARSER_SYM {}
|
2005-07-18 13:31:02 +02:00
|
|
|
| PARTITION_SYM {}
|
2006-12-02 01:47:45 +01:00
|
|
|
| PORT_SYM {}
|
2005-07-06 16:37:57 +02:00
|
|
|
| PREPARE_SYM {}
|
2006-03-20 20:36:21 +01:00
|
|
|
| REMOVE_SYM {}
|
2005-07-06 16:37:57 +02:00
|
|
|
| REPAIR {}
|
|
|
|
| RESET_SYM {}
|
|
|
|
| RESTORE_SYM {}
|
|
|
|
| ROLLBACK_SYM {}
|
|
|
|
| SAVEPOINT_SYM {}
|
|
|
|
| SECURITY_SYM {}
|
2006-12-02 01:47:45 +01:00
|
|
|
| SERVER_SYM {}
|
2005-07-06 16:37:57 +02:00
|
|
|
| SIGNED_SYM {}
|
2006-12-02 01:47:45 +01:00
|
|
|
| SOCKET_SYM {}
|
2005-07-06 16:37:57 +02:00
|
|
|
| SLAVE {}
|
2005-11-06 13:13:06 +01:00
|
|
|
| SONAME_SYM {}
|
2005-07-06 16:37:57 +02:00
|
|
|
| START_SYM {}
|
|
|
|
| STOP_SYM {}
|
|
|
|
| TRUNCATE_SYM {}
|
|
|
|
| UNICODE_SYM {}
|
2005-11-06 13:13:06 +01:00
|
|
|
| UNINSTALL_SYM {}
|
2006-12-02 01:47:45 +01:00
|
|
|
| WRAPPER_SYM {}
|
2005-07-06 16:37:57 +02:00
|
|
|
| XA_SYM {}
|
2006-09-08 12:10:14 +02:00
|
|
|
| UPGRADE_SYM {}
|
2005-07-06 16:37:57 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Keywords that we allow for labels in SPs.
|
2005-07-11 19:10:51 +02:00
|
|
|
* Anything that's the beginning of a statement or characteristics
|
|
|
|
* must be in keyword above, otherwise we get (harmful) shift/reduce
|
|
|
|
* conflicts.
|
2005-07-06 16:37:57 +02:00
|
|
|
*/
|
|
|
|
keyword_sp:
|
2000-07-31 21:29:14 +02:00
|
|
|
ACTION {}
|
2003-06-23 09:56:44 +02:00
|
|
|
| ADDDATE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| AFTER_SYM {}
|
2000-12-07 13:08:48 +01:00
|
|
|
| AGAINST {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| AGGREGATE_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| ALGORITHM_SYM {}
|
2002-11-07 22:45:19 +01:00
|
|
|
| ANY_SYM {}
|
2005-12-05 11:45:04 +01:00
|
|
|
| AT_SYM {}
|
2006-07-20 21:54:01 +02:00
|
|
|
| AUTHORS_SYM {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| AUTO_INC {}
|
2006-01-11 11:35:25 +01:00
|
|
|
| AUTOEXTEND_SIZE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| AVG_ROW_LENGTH {}
|
|
|
|
| AVG_SYM {}
|
2001-10-24 19:52:19 +02:00
|
|
|
| BINLOG_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| BIT_SYM {}
|
|
|
|
| BOOL_SYM {}
|
2001-10-09 14:53:54 +02:00
|
|
|
| BOOLEAN_SYM {}
|
2003-08-26 16:52:54 +02:00
|
|
|
| BTREE_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| CASCADED {}
|
2005-02-01 20:48:05 +01:00
|
|
|
| CHAIN_SYM {}
|
2000-08-17 00:05:02 +02:00
|
|
|
| CHANGED {}
|
2001-09-22 16:32:43 +02:00
|
|
|
| CIPHER_SYM {}
|
2002-06-12 14:04:18 +02:00
|
|
|
| CLIENT_SYM {}
|
2005-08-19 16:26:05 +02:00
|
|
|
| COALESCE {}
|
2005-11-23 13:57:00 +01:00
|
|
|
| CODE_SYM {}
|
2003-02-26 14:02:36 +01:00
|
|
|
| COLLATION_SYM {}
|
2004-12-18 10:48:01 +01:00
|
|
|
| COLUMNS {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| COMMITTED_SYM {}
|
2005-01-07 15:43:27 +01:00
|
|
|
| COMPACT_SYM {}
|
2005-12-02 13:07:02 +01:00
|
|
|
| COMPLETION_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| COMPRESSED_SYM {}
|
2001-05-05 08:41:47 +02:00
|
|
|
| CONCURRENT {}
|
2007-02-07 23:22:19 +01:00
|
|
|
| CONNECTION_SYM {}
|
2004-11-10 17:56:45 +01:00
|
|
|
| CONSISTENT_SYM {}
|
2006-07-20 21:54:01 +02:00
|
|
|
| CONTRIBUTORS_SYM {}
|
2002-07-20 13:51:52 +02:00
|
|
|
| CUBE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| DATA_SYM {}
|
2006-01-11 11:35:25 +01:00
|
|
|
| DATAFILE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| DATETIME {}
|
|
|
|
| DATE_SYM {}
|
|
|
|
| DAY_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| DEFINER_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| DELAY_KEY_WRITE_SYM {}
|
2001-12-13 14:53:18 +01:00
|
|
|
| DES_KEY_FILE {}
|
|
|
|
| DIRECTORY_SYM {}
|
2006-01-24 16:04:35 +01:00
|
|
|
| DISABLE_SYM {}
|
2003-10-14 00:52:03 +02:00
|
|
|
| DISCARD {}
|
2006-01-11 11:35:25 +01:00
|
|
|
| DISK_SYM {}
|
2003-01-21 20:07:59 +01:00
|
|
|
| DUMPFILE {}
|
|
|
|
| DUPLICATE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| DYNAMIC_SYM {}
|
2005-12-02 13:07:02 +01:00
|
|
|
| ENDS_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| ENUM {}
|
2003-12-10 05:31:42 +01:00
|
|
|
| ENGINE_SYM {}
|
2003-12-17 23:52:03 +01:00
|
|
|
| ENGINES_SYM {}
|
2003-08-27 21:30:50 +02:00
|
|
|
| ERRORS {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| ESCAPE_SYM {}
|
2005-12-02 13:07:02 +01:00
|
|
|
| EVENT_SYM {}
|
2001-10-24 19:52:19 +02:00
|
|
|
| EVENTS_SYM {}
|
2005-12-05 11:45:04 +01:00
|
|
|
| EVERY_SYM {}
|
|
|
|
| EXPANSION_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| EXTENDED_SYM {}
|
2006-01-11 11:35:25 +01:00
|
|
|
| EXTENT_SIZE_SYM {}
|
2000-08-17 00:05:02 +02:00
|
|
|
| FAST_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| FOUND_SYM {}
|
2002-08-30 11:40:40 +02:00
|
|
|
| ENABLE_SYM {}
|
2000-09-07 03:55:17 +02:00
|
|
|
| FULL {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| FILE_SYM {}
|
|
|
|
| FIRST_SYM {}
|
|
|
|
| FIXED_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| FRAC_SECOND_SYM {}
|
2003-02-11 12:39:14 +01:00
|
|
|
| GEOMETRY_SYM {}
|
2003-02-28 18:17:08 +01:00
|
|
|
| GEOMETRYCOLLECTION {}
|
2003-10-20 10:24:18 +02:00
|
|
|
| GET_FORMAT {}
|
2002-08-30 11:40:40 +02:00
|
|
|
| GRANTS {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| GLOBAL_SYM {}
|
2003-08-26 16:52:54 +02:00
|
|
|
| HASH_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| HOSTS_SYM {}
|
|
|
|
| HOUR_SYM {}
|
|
|
|
| IDENTIFIED_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| INVOKER_SYM {}
|
2003-10-14 00:52:03 +02:00
|
|
|
| IMPORT {}
|
2001-06-28 09:49:16 +02:00
|
|
|
| INDEXES {}
|
2006-01-11 11:35:25 +01:00
|
|
|
| INITIAL_SIZE_SYM {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| ISOLATION {}
|
2001-09-20 03:45:13 +02:00
|
|
|
| ISSUER_SYM {}
|
2000-10-20 16:39:23 +02:00
|
|
|
| INNOBASE_SYM {}
|
2001-09-22 16:40:57 +02:00
|
|
|
| INSERT_METHOD {}
|
2006-05-03 14:59:17 +02:00
|
|
|
| KEY_BLOCK_SIZE {}
|
2001-04-07 00:18:33 +02:00
|
|
|
| LAST_SYM {}
|
2003-06-12 13:29:02 +02:00
|
|
|
| LEAVES {}
|
2005-07-18 13:31:02 +02:00
|
|
|
| LESS_SYM {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| LEVEL_SYM {}
|
2003-02-11 12:39:14 +01:00
|
|
|
| LINESTRING {}
|
2005-07-18 13:31:02 +02:00
|
|
|
| LIST_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| LOCAL_SYM {}
|
2001-08-21 19:06:00 +02:00
|
|
|
| LOCKS_SYM {}
|
2006-01-11 11:35:25 +01:00
|
|
|
| LOGFILE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| LOGS_SYM {}
|
|
|
|
| MAX_ROWS {}
|
|
|
|
| MASTER_SYM {}
|
|
|
|
| MASTER_HOST_SYM {}
|
|
|
|
| MASTER_PORT_SYM {}
|
|
|
|
| MASTER_LOG_FILE_SYM {}
|
|
|
|
| MASTER_LOG_POS_SYM {}
|
|
|
|
| MASTER_USER_SYM {}
|
|
|
|
| MASTER_PASSWORD_SYM {}
|
2004-02-21 19:10:59 +01:00
|
|
|
| MASTER_SERVER_ID_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| MASTER_CONNECT_RETRY_SYM {}
|
2003-09-01 13:16:20 +02:00
|
|
|
| MASTER_SSL_SYM {}
|
|
|
|
| MASTER_SSL_CA_SYM {}
|
|
|
|
| MASTER_SSL_CAPATH_SYM {}
|
|
|
|
| MASTER_SSL_CERT_SYM {}
|
|
|
|
| MASTER_SSL_CIPHER_SYM {}
|
|
|
|
| MASTER_SSL_KEY_SYM {}
|
2002-08-30 11:40:40 +02:00
|
|
|
| MAX_CONNECTIONS_PER_HOUR {}
|
|
|
|
| MAX_QUERIES_PER_HOUR {}
|
2006-01-11 11:35:25 +01:00
|
|
|
| MAX_SIZE_SYM {}
|
2002-08-30 11:40:40 +02:00
|
|
|
| MAX_UPDATES_PER_HOUR {}
|
2004-12-29 18:30:37 +01:00
|
|
|
| MAX_USER_CONNECTIONS_SYM {}
|
2005-07-18 13:31:02 +02:00
|
|
|
| MAX_VALUE_SYM {}
|
2001-01-16 14:02:25 +01:00
|
|
|
| MEDIUM_SYM {}
|
2006-01-11 11:35:25 +01:00
|
|
|
| MEMORY_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| MERGE_SYM {}
|
2003-07-08 12:06:05 +02:00
|
|
|
| MICROSECOND_SYM {}
|
2005-01-16 13:16:23 +01:00
|
|
|
| MIGRATE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| MINUTE_SYM {}
|
|
|
|
| MIN_ROWS {}
|
|
|
|
| MODIFY_SYM {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| MODE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| MONTH_SYM {}
|
2003-02-11 12:39:14 +01:00
|
|
|
| MULTILINESTRING {}
|
|
|
|
| MULTIPOINT {}
|
|
|
|
| MULTIPOLYGON {}
|
2005-04-12 17:15:54 +02:00
|
|
|
| MUTEX_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| NAME_SYM {}
|
2003-02-26 14:02:36 +01:00
|
|
|
| NAMES_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| NATIONAL_SYM {}
|
|
|
|
| NCHAR_SYM {}
|
2004-04-15 09:14:14 +02:00
|
|
|
| NDBCLUSTER_SYM {}
|
2001-04-07 00:18:33 +02:00
|
|
|
| NEXT_SYM {}
|
2001-09-20 03:45:13 +02:00
|
|
|
| NEW_SYM {}
|
2006-01-11 11:35:25 +01:00
|
|
|
| NO_WAIT_SYM {}
|
|
|
|
| NODEGROUP_SYM {}
|
2002-09-05 15:17:08 +02:00
|
|
|
| NONE_SYM {}
|
2003-09-15 07:26:48 +02:00
|
|
|
| NVARCHAR_SYM {}
|
2002-11-16 19:19:10 +01:00
|
|
|
| OFFSET_SYM {}
|
2003-07-04 18:52:04 +02:00
|
|
|
| OLD_PASSWORD {}
|
2004-06-03 23:17:18 +02:00
|
|
|
| ONE_SHOT_SYM {}
|
2005-01-16 13:16:23 +01:00
|
|
|
| ONE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| PACK_KEYS_SYM {}
|
2002-06-02 20:22:20 +02:00
|
|
|
| PARTIAL {}
|
2006-03-20 20:36:21 +01:00
|
|
|
| PARTITIONING_SYM {}
|
2005-07-18 13:31:02 +02:00
|
|
|
| PARTITIONS_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| PASSWORD {}
|
2005-01-16 13:16:23 +01:00
|
|
|
| PHASE_SYM {}
|
2006-04-06 15:29:39 +02:00
|
|
|
| PLUGIN_SYM {}
|
|
|
|
| PLUGINS_SYM {}
|
2003-02-20 23:14:37 +01:00
|
|
|
| POINT_SYM {}
|
2003-02-11 12:39:14 +01:00
|
|
|
| POLYGON {}
|
2005-12-02 13:07:02 +01:00
|
|
|
| PRESERVE_SYM {}
|
2001-04-07 00:18:33 +02:00
|
|
|
| PREV_SYM {}
|
2004-12-18 10:48:01 +01:00
|
|
|
| PRIVILEGES {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| PROCESS {}
|
|
|
|
| PROCESSLIST_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| QUARTER_SYM {}
|
2001-12-02 13:34:01 +01:00
|
|
|
| QUERY_SYM {}
|
2000-08-17 00:05:02 +02:00
|
|
|
| QUICK {}
|
2006-01-17 08:40:00 +01:00
|
|
|
| REBUILD_SYM {}
|
2005-01-16 13:16:23 +01:00
|
|
|
| RECOVER_SYM {}
|
2006-01-11 11:35:25 +01:00
|
|
|
| REDO_BUFFER_SIZE_SYM {}
|
2006-04-06 15:29:39 +02:00
|
|
|
| REDOFILE_SYM {}
|
2005-02-14 21:50:09 +01:00
|
|
|
| REDUNDANT_SYM {}
|
2002-08-30 11:40:40 +02:00
|
|
|
| RELAY_LOG_FILE_SYM {}
|
|
|
|
| RELAY_LOG_POS_SYM {}
|
2006-05-03 14:59:17 +02:00
|
|
|
| RELAY_THREAD {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| RELOAD {}
|
2006-01-17 08:40:00 +01:00
|
|
|
| REORGANIZE_SYM {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| REPEATABLE_SYM {}
|
2002-06-12 14:04:18 +02:00
|
|
|
| REPLICATION {}
|
2002-05-15 12:50:38 +02:00
|
|
|
| RESOURCES {}
|
2005-01-16 13:16:23 +01:00
|
|
|
| RESUME_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| RETURNS_SYM {}
|
2002-07-20 13:51:52 +02:00
|
|
|
| ROLLUP_SYM {}
|
2004-12-23 11:46:24 +01:00
|
|
|
| ROUTINE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| ROWS_SYM {}
|
|
|
|
| ROW_FORMAT_SYM {}
|
|
|
|
| ROW_SYM {}
|
2003-08-26 16:52:54 +02:00
|
|
|
| RTREE_SYM {}
|
2005-12-05 11:45:04 +01:00
|
|
|
| SCHEDULE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| SECOND_SYM {}
|
2002-11-20 20:44:32 +01:00
|
|
|
| SERIAL_SYM {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| SERIALIZABLE_SYM {}
|
|
|
|
| SESSION_SYM {}
|
2002-06-02 20:22:20 +02:00
|
|
|
| SIMPLE_SYM {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| SHARE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| SHUTDOWN {}
|
2004-11-10 17:56:45 +01:00
|
|
|
| SNAPSHOT_SYM {}
|
2003-06-04 18:21:51 +02:00
|
|
|
| SOUNDS_SYM {}
|
2001-12-02 13:34:01 +01:00
|
|
|
| SQL_CACHE_SYM {}
|
2002-07-23 17:31:22 +02:00
|
|
|
| SQL_BUFFER_RESULT {}
|
2001-12-02 13:34:01 +01:00
|
|
|
| SQL_NO_CACHE_SYM {}
|
2002-08-30 11:40:40 +02:00
|
|
|
| SQL_THREAD {}
|
2005-12-02 13:07:02 +01:00
|
|
|
| STARTS_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| STATUS_SYM {}
|
2003-12-17 23:52:03 +01:00
|
|
|
| STORAGE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| STRING_SYM {}
|
2003-06-23 09:56:44 +02:00
|
|
|
| SUBDATE_SYM {}
|
2001-09-20 03:45:13 +02:00
|
|
|
| SUBJECT_SYM {}
|
2005-07-18 13:31:02 +02:00
|
|
|
| SUBPARTITION_SYM {}
|
|
|
|
| SUBPARTITIONS_SYM {}
|
2002-06-12 14:04:18 +02:00
|
|
|
| SUPER_SYM {}
|
2005-01-16 13:16:23 +01:00
|
|
|
| SUSPEND_SYM {}
|
2004-12-18 10:48:01 +01:00
|
|
|
| TABLES {}
|
2003-10-14 00:52:03 +02:00
|
|
|
| TABLESPACE {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| TEMPORARY {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| TEMPTABLE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| TEXT_SYM {}
|
2005-07-18 13:31:02 +02:00
|
|
|
| THAN_SYM {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| TRANSACTION_SYM {}
|
2005-07-19 18:06:49 +02:00
|
|
|
| TRIGGERS_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| TIMESTAMP {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| TIMESTAMP_ADD {}
|
|
|
|
| TIMESTAMP_DIFF {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| TIME_SYM {}
|
2003-12-17 23:52:03 +01:00
|
|
|
| TYPES_SYM {}
|
2005-04-12 23:08:19 +02:00
|
|
|
| TYPE_SYM {}
|
2004-09-13 11:19:38 +02:00
|
|
|
| UDF_RETURNS_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| FUNCTION_SYM {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| UNCOMMITTED_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| UNDEFINED_SYM {}
|
2006-01-11 11:35:25 +01:00
|
|
|
| UNDO_BUFFER_SIZE_SYM {}
|
|
|
|
| UNDOFILE_SYM {}
|
2004-11-17 16:49:10 +01:00
|
|
|
| UNKNOWN_SYM {}
|
2003-09-13 22:13:41 +02:00
|
|
|
| UNTIL_SYM {}
|
2003-06-06 14:43:23 +02:00
|
|
|
| USER {}
|
2002-03-13 18:20:17 +01:00
|
|
|
| USE_FRM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| VARIABLES {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| VIEW_SYM {}
|
2002-11-20 20:44:32 +01:00
|
|
|
| VALUE_SYM {}
|
2003-08-27 21:30:50 +02:00
|
|
|
| WARNINGS {}
|
2006-01-11 11:35:25 +01:00
|
|
|
| WAIT_SYM {}
|
2004-11-12 04:01:46 +01:00
|
|
|
| WEEK_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| WORK_SYM {}
|
2003-05-29 11:52:25 +02:00
|
|
|
| X509_SYM {}
|
2002-08-30 11:40:40 +02:00
|
|
|
| YEAR_SYM {}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
/* Option functions */
|
|
|
|
|
|
|
|
set:
|
|
|
|
SET opt_option
|
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_SET_OPTION;
|
2005-01-05 15:48:23 +01:00
|
|
|
mysql_init_select(lex);
|
2004-03-24 16:33:47 +01:00
|
|
|
lex->option_type=OPT_SESSION;
|
2002-07-23 17:31:22 +02:00
|
|
|
lex->var_list.empty();
|
2004-06-03 23:17:18 +02:00
|
|
|
lex->one_shot_set= 0;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
option_value_list
|
|
|
|
{}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_option:
|
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| OPTION {};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
option_value_list:
|
2005-03-04 14:35:28 +01:00
|
|
|
option_type_value
|
|
|
|
| option_value_list ',' option_type_value;
|
|
|
|
|
|
|
|
option_type_value:
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
|
|
|
|
|
|
|
if (lex->sphead)
|
2005-03-04 14:35:28 +01:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
If we are in SP we want have own LEX for each assignment.
|
|
|
|
This is mostly because it is hard for several sp_instr_set
|
2005-05-17 17:08:43 +02:00
|
|
|
and sp_instr_set_trigger instructions share one LEX.
|
|
|
|
(Well, it is theoretically possible but adds some extra
|
2005-03-04 14:35:28 +01:00
|
|
|
overhead on preparation for execution stage and IMO less
|
|
|
|
robust).
|
|
|
|
|
|
|
|
QQ: May be we should simply prohibit group assignments in SP?
|
|
|
|
*/
|
2007-04-26 05:38:12 +02:00
|
|
|
lex->sphead->reset_lex(thd);
|
|
|
|
lex= thd->lex;
|
2005-05-17 17:08:43 +02:00
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
/* Set new LEX as if we at start of set rule. */
|
|
|
|
lex->sql_command= SQLCOM_SET_OPTION;
|
|
|
|
mysql_init_select(lex);
|
|
|
|
lex->option_type=OPT_SESSION;
|
|
|
|
lex->var_list.empty();
|
|
|
|
lex->one_shot_set= 0;
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
lex->sphead->m_tmp_query= lip->get_tok_start();
|
2005-03-04 14:35:28 +01:00
|
|
|
}
|
|
|
|
}
|
2005-05-18 09:47:45 +02:00
|
|
|
ext_option_value
|
2005-03-04 14:35:28 +01:00
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2005-05-17 17:08:43 +02:00
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
if (lex->sphead)
|
|
|
|
{
|
|
|
|
sp_head *sp= lex->sphead;
|
2005-05-17 17:08:43 +02:00
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
if (!lex->var_list.is_empty())
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
We have assignment to user or system variable or
|
|
|
|
option setting, so we should construct sp_instr_stmt
|
|
|
|
for it.
|
|
|
|
*/
|
|
|
|
LEX_STRING qbuff;
|
|
|
|
sp_instr_stmt *i;
|
2005-05-17 17:08:43 +02:00
|
|
|
|
2005-03-04 14:35:28 +01:00
|
|
|
if (!(i= new sp_instr_stmt(sp->instructions(), lex->spcont,
|
|
|
|
lex)))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-05-17 17:08:43 +02:00
|
|
|
|
2006-07-07 19:24:54 +02:00
|
|
|
/*
|
|
|
|
Extract the query statement from the tokenizer. The
|
2007-04-26 05:38:12 +02:00
|
|
|
end is either lip->ptr, if there was no lookahead,
|
|
|
|
lip->tok_end otherwise.
|
2006-07-07 19:24:54 +02:00
|
|
|
*/
|
|
|
|
if (yychar == YYEMPTY)
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
qbuff.length= lip->get_ptr() - sp->m_tmp_query;
|
2005-03-04 14:35:28 +01:00
|
|
|
else
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
qbuff.length= lip->get_tok_end() - sp->m_tmp_query;
|
2005-05-17 17:08:43 +02:00
|
|
|
|
2007-05-24 18:47:58 +02:00
|
|
|
if (!(qbuff.str= (char*) alloc_root(thd->mem_root,
|
2007-05-28 13:37:39 +02:00
|
|
|
qbuff.length + 5)))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-05-17 17:08:43 +02:00
|
|
|
|
2007-03-27 19:09:56 +02:00
|
|
|
strmake(strmake(qbuff.str, "SET ", 4), sp->m_tmp_query,
|
2005-03-04 14:35:28 +01:00
|
|
|
qbuff.length);
|
|
|
|
qbuff.length+= 4;
|
|
|
|
i->m_query= qbuff;
|
|
|
|
sp->add_instr(i);
|
|
|
|
}
|
2007-04-26 05:38:12 +02:00
|
|
|
lex->sphead->restore_lex(thd);
|
2005-03-04 14:35:28 +01:00
|
|
|
}
|
|
|
|
};
|
2002-07-23 17:31:22 +02:00
|
|
|
|
|
|
|
option_type:
|
2005-05-18 09:47:45 +02:00
|
|
|
option_type2 {}
|
|
|
|
| GLOBAL_SYM { $$=OPT_GLOBAL; }
|
|
|
|
| LOCAL_SYM { $$=OPT_SESSION; }
|
|
|
|
| SESSION_SYM { $$=OPT_SESSION; }
|
|
|
|
;
|
|
|
|
|
|
|
|
option_type2:
|
|
|
|
/* empty */ { $$= OPT_DEFAULT; }
|
|
|
|
| ONE_SHOT_SYM { Lex->one_shot_set= 1; $$= OPT_SESSION; }
|
2002-07-23 17:31:22 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
opt_var_type:
|
|
|
|
/* empty */ { $$=OPT_SESSION; }
|
2002-08-30 11:40:40 +02:00
|
|
|
| GLOBAL_SYM { $$=OPT_GLOBAL; }
|
2002-07-23 17:31:22 +02:00
|
|
|
| LOCAL_SYM { $$=OPT_SESSION; }
|
|
|
|
| SESSION_SYM { $$=OPT_SESSION; }
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_var_ident_type:
|
|
|
|
/* empty */ { $$=OPT_DEFAULT; }
|
2002-08-30 11:40:40 +02:00
|
|
|
| GLOBAL_SYM '.' { $$=OPT_GLOBAL; }
|
2002-07-23 17:31:22 +02:00
|
|
|
| LOCAL_SYM '.' { $$=OPT_SESSION; }
|
|
|
|
| SESSION_SYM '.' { $$=OPT_SESSION; }
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-05-18 09:47:45 +02:00
|
|
|
ext_option_value:
|
|
|
|
sys_option_value
|
|
|
|
| option_type2 option_value;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2005-05-18 09:47:45 +02:00
|
|
|
sys_option_value:
|
|
|
|
option_type internal_variable_name equal set_expr_or_default
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2004-11-24 10:24:02 +01:00
|
|
|
|
2005-11-06 01:36:40 +01:00
|
|
|
if ($2.var == trg_new_row_fake_var)
|
2005-05-18 09:47:45 +02:00
|
|
|
{
|
|
|
|
/* We are in trigger and assigning value to field of new row */
|
|
|
|
Item *it;
|
2005-05-27 12:15:17 +02:00
|
|
|
Item_trigger_field *trg_fld;
|
2005-08-12 12:54:42 +02:00
|
|
|
sp_instr_set_trigger_field *sp_fld;
|
|
|
|
LINT_INIT(sp_fld);
|
2005-05-18 09:47:45 +02:00
|
|
|
if ($1)
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2005-05-18 09:47:45 +02:00
|
|
|
if ($4)
|
|
|
|
it= $4;
|
2004-11-12 04:01:46 +01:00
|
|
|
else
|
2005-05-18 09:47:45 +02:00
|
|
|
{
|
|
|
|
/* QQ: Shouldn't this be field's default value ? */
|
|
|
|
it= new Item_null();
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2006-05-12 11:55:21 +02:00
|
|
|
DBUG_ASSERT(lex->trg_chistics.action_time == TRG_ACTION_BEFORE &&
|
|
|
|
(lex->trg_chistics.event == TRG_EVENT_INSERT ||
|
|
|
|
lex->trg_chistics.event == TRG_EVENT_UPDATE));
|
2005-08-12 16:57:19 +02:00
|
|
|
if (!(trg_fld= new Item_trigger_field(Lex->current_context(),
|
2005-07-01 06:05:42 +02:00
|
|
|
Item_trigger_field::NEW_ROW,
|
2006-01-24 18:15:12 +01:00
|
|
|
$2.base_name.str,
|
2006-05-12 11:55:21 +02:00
|
|
|
UPDATE_ACL, FALSE)) ||
|
2005-08-12 12:54:42 +02:00
|
|
|
!(sp_fld= new sp_instr_set_trigger_field(lex->sphead->
|
|
|
|
instructions(),
|
|
|
|
lex->spcont,
|
|
|
|
trg_fld,
|
|
|
|
it, lex)))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2005-05-18 09:47:45 +02:00
|
|
|
/*
|
|
|
|
Let us add this item to list of all Item_trigger_field
|
|
|
|
objects in trigger.
|
|
|
|
*/
|
WL#3817: Simplify string / memory area types and make things more consistent (first part)
The following type conversions was done:
- Changed byte to uchar
- Changed gptr to uchar*
- Change my_string to char *
- Change my_size_t to size_t
- Change size_s to size_t
Removed declaration of byte, gptr, my_string, my_size_t and size_s.
Following function parameter changes was done:
- All string functions in mysys/strings was changed to use size_t
instead of uint for string lengths.
- All read()/write() functions changed to use size_t (including vio).
- All protocoll functions changed to use size_t instead of uint
- Functions that used a pointer to a string length was changed to use size_t*
- Changed malloc(), free() and related functions from using gptr to use void *
as this requires fewer casts in the code and is more in line with how the
standard functions work.
- Added extra length argument to dirname_part() to return the length of the
created string.
- Changed (at least) following functions to take uchar* as argument:
- db_dump()
- my_net_write()
- net_write_command()
- net_store_data()
- DBUG_DUMP()
- decimal2bin() & bin2decimal()
- Changed my_compress() and my_uncompress() to use size_t. Changed one
argument to my_uncompress() from a pointer to a value as we only return
one value (makes function easier to use).
- Changed type of 'pack_data' argument to packfrm() to avoid casts.
- Changed in readfrm() and writefrom(), ha_discover and handler::discover()
the type for argument 'frmdata' to uchar** to avoid casts.
- Changed most Field functions to use uchar* instead of char* (reduced a lot of
casts).
- Changed field->val_xxx(xxx, new_ptr) to take const pointers.
Other changes:
- Removed a lot of not needed casts
- Added a few new cast required by other changes
- Added some cast to my_multi_malloc() arguments for safety (as string lengths
needs to be uint, not size_t).
- Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
explicitely as this conflict was often hided by casting the function to
hash_get_key).
- Changed some buffers to memory regions to uchar* to avoid casts.
- Changed some string lengths from uint to size_t.
- Changed field->ptr to be uchar* instead of char*. This allowed us to
get rid of a lot of casts.
- Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
- Include zlib.h in some files as we needed declaration of crc32()
- Changed MY_FILE_ERROR to be (size_t) -1.
- Changed many variables to hold the result of my_read() / my_write() to be
size_t. This was needed to properly detect errors (which are
returned as (size_t) -1).
- Removed some very old VMS code
- Changed packfrm()/unpackfrm() to not be depending on uint size
(portability fix)
- Removed windows specific code to restore cursor position as this
causes slowdown on windows and we should not mix read() and pread()
calls anyway as this is not thread safe. Updated function comment to
reflect this. Changed function that depended on original behavior of
my_pwrite() to itself restore the cursor position (one such case).
- Added some missing checking of return value of malloc().
- Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
- Changed type of table_def::m_size from my_size_t to ulong to reflect that
m_size is the number of elements in the array, not a string/memory
length.
- Moved THD::max_row_length() to table.cc (as it's not depending on THD).
Inlined max_row_length_blob() into this function.
- More function comments
- Fixed some compiler warnings when compiled without partitions.
- Removed setting of LEX_STRING() arguments in declaration (portability fix).
- Some trivial indentation/variable name changes.
- Some trivial code simplifications:
- Replaced some calls to alloc_root + memcpy to use
strmake_root()/strdup_root().
- Changed some calls from memdup() to strmake() (Safety fix)
- Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
|
|
|
lex->trg_table_fields.link_in_list((uchar *)trg_fld,
|
|
|
|
(uchar **) &trg_fld->
|
|
|
|
next_trg_field);
|
2005-05-18 09:47:45 +02:00
|
|
|
|
2005-08-12 12:54:42 +02:00
|
|
|
lex->sphead->add_instr(sp_fld);
|
2005-05-18 09:47:45 +02:00
|
|
|
}
|
|
|
|
else if ($2.var)
|
|
|
|
{ /* System variable */
|
|
|
|
if ($1)
|
2005-08-27 15:51:11 +02:00
|
|
|
lex->option_type= $1;
|
2005-05-18 09:47:45 +02:00
|
|
|
lex->var_list.push_back(new set_var(lex->option_type, $2.var,
|
|
|
|
&$2.base_name, $4));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* An SP local variable */
|
|
|
|
sp_pcontext *ctx= lex->spcont;
|
2006-04-07 16:53:15 +02:00
|
|
|
sp_variable_t *spv;
|
2005-08-12 12:54:42 +02:00
|
|
|
sp_instr_set *sp_set;
|
2005-05-18 09:47:45 +02:00
|
|
|
Item *it;
|
|
|
|
if ($1)
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2005-05-18 09:47:45 +02:00
|
|
|
}
|
|
|
|
|
2006-04-07 16:53:15 +02:00
|
|
|
spv= ctx->find_variable(&$2.base_name);
|
2005-05-18 09:47:45 +02:00
|
|
|
|
|
|
|
if ($4)
|
|
|
|
it= $4;
|
|
|
|
else if (spv->dflt)
|
|
|
|
it= spv->dflt;
|
|
|
|
else
|
|
|
|
it= new Item_null();
|
2005-08-12 12:54:42 +02:00
|
|
|
sp_set= new sp_instr_set(lex->sphead->instructions(), ctx,
|
|
|
|
spv->offset, it, spv->type, lex, TRUE);
|
|
|
|
lex->sphead->add_instr(sp_set);
|
2005-05-18 09:47:45 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
| option_type TRANSACTION_SYM ISOLATION LEVEL_SYM isolation_types
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2005-11-03 01:38:23 +01:00
|
|
|
lex->option_type= $1;
|
2005-05-18 09:47:45 +02:00
|
|
|
lex->var_list.push_back(new set_var(lex->option_type,
|
2007-03-02 17:43:45 +01:00
|
|
|
find_sys_var(YYTHD, "tx_isolation"),
|
2005-05-18 09:47:45 +02:00
|
|
|
&null_lex_str,
|
|
|
|
new Item_int((int32) $5)));
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
option_value:
|
|
|
|
'@' ident_or_text equal expr
|
|
|
|
{
|
|
|
|
Lex->var_list.push_back(new set_var_user(new Item_func_set_user_var($2,$4)));
|
|
|
|
}
|
2002-07-25 00:00:56 +02:00
|
|
|
| '@' '@' opt_var_ident_type internal_variable_name equal set_expr_or_default
|
2002-07-23 17:31:22 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2005-08-27 15:51:11 +02:00
|
|
|
lex->var_list.push_back(new set_var($3, $4.var, &$4.base_name, $6));
|
2002-07-23 17:31:22 +02:00
|
|
|
}
|
2003-05-21 14:44:12 +02:00
|
|
|
| charset old_or_new_charset_name_or_default
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2003-03-18 14:01:32 +01:00
|
|
|
THD *thd= YYTHD;
|
2007-01-27 02:46:45 +01:00
|
|
|
LEX *lex= thd->lex;
|
2003-05-21 14:44:12 +02:00
|
|
|
$2= $2 ? $2: global_system_variables.character_set_client;
|
2003-09-15 13:31:04 +02:00
|
|
|
lex->var_list.push_back(new set_var_collation_client($2,thd->variables.collation_database,$2));
|
2003-02-26 14:02:36 +01:00
|
|
|
}
|
2005-10-11 15:01:38 +02:00
|
|
|
| NAMES_SYM equal expr
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_pcontext *spc= lex->spcont;
|
|
|
|
LEX_STRING names;
|
|
|
|
|
|
|
|
names.str= (char *)"names";
|
|
|
|
names.length= 5;
|
2006-04-07 16:53:15 +02:00
|
|
|
if (spc && spc->find_variable(&names))
|
2005-10-11 15:01:38 +02:00
|
|
|
my_error(ER_SP_BAD_VAR_SHADOW, MYF(0), names.str);
|
2005-11-18 23:22:12 +01:00
|
|
|
else
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
2005-11-18 23:22:12 +01:00
|
|
|
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-10-11 15:01:38 +02:00
|
|
|
}
|
2003-03-05 09:37:39 +01:00
|
|
|
| NAMES_SYM charset_name_or_default opt_collate
|
2003-03-07 08:54:26 +01:00
|
|
|
{
|
2003-04-05 15:56:15 +02:00
|
|
|
LEX *lex= Lex;
|
2003-05-21 14:44:12 +02:00
|
|
|
$2= $2 ? $2 : global_system_variables.character_set_client;
|
2003-04-08 11:38:17 +02:00
|
|
|
$3= $3 ? $3 : $2;
|
|
|
|
if (!my_charset_same($2,$3))
|
2003-03-07 08:54:26 +01:00
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_COLLATION_CHARSET_MISMATCH, MYF(0),
|
|
|
|
$3->name, $2->csname);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-03-07 08:54:26 +01:00
|
|
|
}
|
2003-05-30 20:09:35 +02:00
|
|
|
lex->var_list.push_back(new set_var_collation_client($3,$3,$3));
|
2003-03-07 08:54:26 +01:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| PASSWORD equal text_or_password
|
2001-06-28 09:49:16 +02:00
|
|
|
{
|
2007-01-27 02:46:45 +01:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
2002-07-23 17:31:22 +02:00
|
|
|
LEX_USER *user;
|
2005-10-11 15:01:38 +02:00
|
|
|
sp_pcontext *spc= lex->spcont;
|
|
|
|
LEX_STRING pw;
|
|
|
|
|
|
|
|
pw.str= (char *)"password";
|
|
|
|
pw.length= 8;
|
2006-04-07 16:53:15 +02:00
|
|
|
if (spc && spc->find_variable(&pw))
|
2005-10-11 15:01:38 +02:00
|
|
|
{
|
|
|
|
my_error(ER_SP_BAD_VAR_SHADOW, MYF(0), pw.str);
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-10-11 15:01:38 +02:00
|
|
|
}
|
2002-12-06 20:11:27 +01:00
|
|
|
if (!(user=(LEX_USER*) thd->alloc(sizeof(LEX_USER))))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-01-16 13:16:23 +01:00
|
|
|
user->host=null_lex_str;
|
2005-09-15 21:29:07 +02:00
|
|
|
user->user.str=thd->security_ctx->priv_user;
|
2003-12-19 18:52:13 +01:00
|
|
|
thd->lex->var_list.push_back(new set_var_password(user, $3));
|
2002-07-23 17:31:22 +02:00
|
|
|
}
|
|
|
|
| PASSWORD FOR_SYM user equal text_or_password
|
2001-06-28 09:49:16 +02:00
|
|
|
{
|
2002-07-23 17:31:22 +02:00
|
|
|
Lex->var_list.push_back(new set_var_password($3,$5));
|
|
|
|
}
|
2002-10-12 11:07:54 +02:00
|
|
|
;
|
2001-06-28 09:49:16 +02:00
|
|
|
|
2002-07-23 17:31:22 +02:00
|
|
|
internal_variable_name:
|
|
|
|
ident
|
|
|
|
{
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
2004-11-12 04:01:46 +01:00
|
|
|
sp_pcontext *spc= lex->spcont;
|
2006-04-07 16:53:15 +02:00
|
|
|
sp_variable_t *spv;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
|
|
|
/* We have to lookup here since local vars can shadow sysvars */
|
2006-04-07 16:53:15 +02:00
|
|
|
if (!spc || !(spv = spc->find_variable(&$1)))
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
/* Not an SP local variable */
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
sys_var *tmp=find_sys_var(thd, $1.str, $1.length);
|
2004-11-12 04:01:46 +01:00
|
|
|
if (!tmp)
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
$$.var= tmp;
|
2005-01-16 13:16:23 +01:00
|
|
|
$$.base_name= null_lex_str;
|
BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked
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.
2007-03-09 11:12:31 +01:00
|
|
|
if (spc && tmp == &sys_autocommit)
|
2005-09-14 10:54:02 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
We don't allow setting AUTOCOMMIT from a stored function
|
|
|
|
or trigger.
|
|
|
|
*/
|
|
|
|
lex->sphead->m_flags|= sp_head::HAS_SET_AUTOCOMMIT_STMT;
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* An SP local variable */
|
|
|
|
$$.var= NULL;
|
|
|
|
$$.base_name= $1;
|
|
|
|
}
|
2002-07-23 17:31:22 +02:00
|
|
|
}
|
2003-07-06 18:09:57 +02:00
|
|
|
| ident '.' ident
|
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
2004-03-16 11:01:05 +01:00
|
|
|
if (check_reserved_words(&$1))
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2004-03-16 11:01:05 +01:00
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
if (lex->sphead && lex->sphead->m_type == TYPE_ENUM_TRIGGER &&
|
|
|
|
(!my_strcasecmp(system_charset_info, $1.str, "NEW") ||
|
|
|
|
!my_strcasecmp(system_charset_info, $1.str, "OLD")))
|
|
|
|
{
|
|
|
|
if ($1.str[0]=='O' || $1.str[0]=='o')
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_TRG_CANT_CHANGE_ROW, MYF(0), "OLD", "");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
if (lex->trg_chistics.event == TRG_EVENT_DELETE)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_TRG_NO_SUCH_ROW_IN_TRG, MYF(0),
|
|
|
|
"NEW", "on DELETE");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
if (lex->trg_chistics.action_time == TRG_ACTION_AFTER)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_TRG_CANT_CHANGE_ROW, MYF(0), "NEW", "after ");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
/* This special combination will denote field of NEW row */
|
2005-11-06 01:36:40 +01:00
|
|
|
$$.var= trg_new_row_fake_var;
|
2004-11-12 04:01:46 +01:00
|
|
|
$$.base_name= $3;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2007-03-02 17:43:45 +01:00
|
|
|
sys_var *tmp=find_sys_var(YYTHD, $3.str, $3.length);
|
2004-11-12 04:01:46 +01:00
|
|
|
if (!tmp)
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
if (!tmp->is_struct())
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_VARIABLE_IS_NOT_STRUCT, MYF(0), $3.str);
|
2004-11-12 04:01:46 +01:00
|
|
|
$$.var= tmp;
|
|
|
|
$$.base_name= $1;
|
|
|
|
}
|
2003-07-06 18:09:57 +02:00
|
|
|
}
|
|
|
|
| DEFAULT '.' ident
|
|
|
|
{
|
2007-03-02 17:43:45 +01:00
|
|
|
sys_var *tmp=find_sys_var(YYTHD, $3.str, $3.length);
|
2003-07-06 18:09:57 +02:00
|
|
|
if (!tmp)
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-07-06 18:09:57 +02:00
|
|
|
if (!tmp->is_struct())
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_VARIABLE_IS_NOT_STRUCT, MYF(0), $3.str);
|
2003-08-18 23:08:08 +02:00
|
|
|
$$.var= tmp;
|
|
|
|
$$.base_name.str= (char*) "default";
|
|
|
|
$$.base_name.length= 7;
|
2003-07-06 18:09:57 +02:00
|
|
|
}
|
2002-10-16 15:55:08 +02:00
|
|
|
;
|
2002-07-23 17:31:22 +02:00
|
|
|
|
|
|
|
isolation_types:
|
|
|
|
READ_SYM UNCOMMITTED_SYM { $$= ISO_READ_UNCOMMITTED; }
|
|
|
|
| READ_SYM COMMITTED_SYM { $$= ISO_READ_COMMITTED; }
|
|
|
|
| REPEATABLE_SYM READ_SYM { $$= ISO_REPEATABLE_READ; }
|
|
|
|
| SERIALIZABLE_SYM { $$= ISO_SERIALIZABLE; }
|
|
|
|
;
|
2002-12-04 23:14:51 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
text_or_password:
|
|
|
|
TEXT_STRING { $$=$1.str;}
|
|
|
|
| PASSWORD '(' TEXT_STRING ')'
|
|
|
|
{
|
2003-07-08 00:36:14 +02:00
|
|
|
$$= $3.length ? YYTHD->variables.old_passwords ?
|
2003-07-04 18:52:04 +02:00
|
|
|
Item_func_old_password::alloc(YYTHD, $3.str) :
|
|
|
|
Item_func_password::alloc(YYTHD, $3.str) :
|
|
|
|
$3.str;
|
|
|
|
}
|
|
|
|
| OLD_PASSWORD '(' TEXT_STRING ')'
|
|
|
|
{
|
|
|
|
$$= $3.length ? Item_func_old_password::alloc(YYTHD, $3.str) :
|
|
|
|
$3.str;
|
2002-10-16 15:55:08 +02:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-03-21 00:02:22 +01:00
|
|
|
|
2002-07-25 00:00:56 +02:00
|
|
|
set_expr_or_default:
|
2002-07-23 17:31:22 +02:00
|
|
|
expr { $$=$1; }
|
|
|
|
| DEFAULT { $$=0; }
|
2002-10-02 12:33:08 +02:00
|
|
|
| ON { $$=new Item_string("ON", 2, system_charset_info); }
|
|
|
|
| ALL { $$=new Item_string("ALL", 3, system_charset_info); }
|
2003-02-27 14:45:40 +01:00
|
|
|
| BINARY { $$=new Item_string("binary", 6, system_charset_info); }
|
2002-07-23 17:31:22 +02:00
|
|
|
;
|
2001-03-21 00:02:22 +01:00
|
|
|
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/* Lock function */
|
|
|
|
|
|
|
|
lock:
|
|
|
|
LOCK_SYM table_or_tables
|
|
|
|
{
|
2005-02-08 20:52:50 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
|
|
|
|
if (lex->sphead)
|
|
|
|
{
|
2005-03-30 17:43:52 +02:00
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "LOCK");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-02-08 20:52:50 +01:00
|
|
|
}
|
|
|
|
lex->sql_command= SQLCOM_LOCK_TABLES;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2004-12-27 12:08:22 +01:00
|
|
|
table_lock_list
|
|
|
|
{}
|
2002-11-28 18:57:56 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
table_or_tables:
|
|
|
|
TABLE_SYM
|
2002-04-16 01:09:30 +02:00
|
|
|
| TABLES;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
table_lock_list:
|
|
|
|
table_lock
|
2002-04-16 01:09:30 +02:00
|
|
|
| table_lock_list ',' table_lock;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
table_lock:
|
|
|
|
table_ident opt_table_alias lock_option
|
2002-10-30 12:18:52 +01:00
|
|
|
{
|
2002-12-06 20:11:27 +01:00
|
|
|
if (!Select->add_table_to_list(YYTHD, $1, $2, 0, (thr_lock_type) $3))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-10-30 12:18:52 +01:00
|
|
|
}
|
2002-10-16 15:55:08 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
lock_option:
|
|
|
|
READ_SYM { $$=TL_READ_NO_INSERT; }
|
2007-06-03 08:40:00 +02:00
|
|
|
| WRITE_SYM { $$=TL_WRITE_DEFAULT; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| LOW_PRIORITY WRITE_SYM { $$=TL_WRITE_LOW_PRIORITY; }
|
2002-10-16 15:55:08 +02:00
|
|
|
| READ_SYM LOCAL_SYM { $$= TL_READ; }
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
unlock:
|
2005-02-08 20:52:50 +01:00
|
|
|
UNLOCK_SYM
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
|
|
|
|
if (lex->sphead)
|
|
|
|
{
|
2005-03-30 17:43:52 +02:00
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "UNLOCK");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-02-08 20:52:50 +01:00
|
|
|
}
|
|
|
|
lex->sql_command= SQLCOM_UNLOCK_TABLES;
|
|
|
|
}
|
|
|
|
table_or_tables
|
|
|
|
{}
|
2002-10-16 15:55:08 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
2001-04-07 00:18:33 +02:00
|
|
|
/*
|
2001-04-13 16:18:44 +02:00
|
|
|
** Handler: direct access to ISAM functions
|
2001-04-07 00:18:33 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
handler:
|
|
|
|
HANDLER_SYM table_ident OPEN_SYM opt_table_alias
|
|
|
|
{
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX *lex= Lex;
|
2005-09-07 21:03:56 +02:00
|
|
|
if (lex->sphead)
|
|
|
|
{
|
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "HANDLER");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-09-07 21:03:56 +02:00
|
|
|
}
|
2002-10-30 12:18:52 +01:00
|
|
|
lex->sql_command = SQLCOM_HA_OPEN;
|
2002-12-06 20:11:27 +01:00
|
|
|
if (!lex->current_select->add_table_to_list(lex->thd, $2, $4, 0))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2001-04-07 00:18:33 +02:00
|
|
|
}
|
2004-06-26 14:21:32 +02:00
|
|
|
| HANDLER_SYM table_ident_nodb CLOSE_SYM
|
2001-04-07 00:18:33 +02:00
|
|
|
{
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX *lex= Lex;
|
2005-09-07 21:03:56 +02:00
|
|
|
if (lex->sphead)
|
|
|
|
{
|
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "HANDLER");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-09-07 21:03:56 +02:00
|
|
|
}
|
2002-10-30 12:18:52 +01:00
|
|
|
lex->sql_command = SQLCOM_HA_CLOSE;
|
2002-12-06 20:11:27 +01:00
|
|
|
if (!lex->current_select->add_table_to_list(lex->thd, $2, 0, 0))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2001-04-07 00:18:33 +02:00
|
|
|
}
|
2004-06-26 14:21:32 +02:00
|
|
|
| HANDLER_SYM table_ident_nodb READ_SYM
|
2001-04-07 00:18:33 +02:00
|
|
|
{
|
2001-11-05 23:05:45 +01:00
|
|
|
LEX *lex=Lex;
|
2005-09-07 21:03:56 +02:00
|
|
|
if (lex->sphead)
|
|
|
|
{
|
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "HANDLER");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-09-07 21:03:56 +02:00
|
|
|
}
|
2006-08-23 16:53:04 +02:00
|
|
|
lex->expr_allows_subselect= FALSE;
|
2001-11-05 23:05:45 +01:00
|
|
|
lex->sql_command = SQLCOM_HA_READ;
|
|
|
|
lex->ha_rkey_mode= HA_READ_KEY_EXACT; /* Avoid purify warnings */
|
2005-06-08 08:37:43 +02:00
|
|
|
lex->current_select->select_limit= new Item_int((int32) 1);
|
2005-06-07 12:11:36 +02:00
|
|
|
lex->current_select->offset_limit= 0;
|
2002-12-06 20:11:27 +01:00
|
|
|
if (!lex->current_select->add_table_to_list(lex->thd, $2, 0, 0))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2001-04-13 16:18:44 +02:00
|
|
|
}
|
2006-08-23 16:53:04 +02:00
|
|
|
handler_read_or_scan where_clause opt_limit_clause
|
|
|
|
{
|
|
|
|
Lex->expr_allows_subselect= TRUE;
|
|
|
|
}
|
2002-10-16 15:55:08 +02:00
|
|
|
;
|
2001-04-07 00:18:33 +02:00
|
|
|
|
2001-04-13 16:18:44 +02:00
|
|
|
handler_read_or_scan:
|
2005-01-16 13:16:23 +01:00
|
|
|
handler_scan_function { Lex->ident= null_lex_str; }
|
|
|
|
| ident handler_rkey_function { Lex->ident= $1; }
|
2002-10-16 15:55:08 +02:00
|
|
|
;
|
2001-04-13 16:18:44 +02:00
|
|
|
|
|
|
|
handler_scan_function:
|
|
|
|
FIRST_SYM { Lex->ha_read_mode = RFIRST; }
|
2002-10-16 15:55:08 +02:00
|
|
|
| NEXT_SYM { Lex->ha_read_mode = RNEXT; }
|
|
|
|
;
|
2001-04-13 16:18:44 +02:00
|
|
|
|
|
|
|
handler_rkey_function:
|
|
|
|
FIRST_SYM { Lex->ha_read_mode = RFIRST; }
|
|
|
|
| NEXT_SYM { Lex->ha_read_mode = RNEXT; }
|
|
|
|
| PREV_SYM { Lex->ha_read_mode = RPREV; }
|
|
|
|
| LAST_SYM { Lex->ha_read_mode = RLAST; }
|
2001-04-07 00:18:33 +02:00
|
|
|
| handler_rkey_mode
|
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->ha_read_mode = RKEY;
|
2001-11-05 23:05:45 +01:00
|
|
|
lex->ha_rkey_mode=$1;
|
2001-06-15 04:03:15 +02:00
|
|
|
if (!(lex->insert_list = new List_item))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-10-16 15:55:08 +02:00
|
|
|
} '(' values ')' { }
|
|
|
|
;
|
2001-04-07 00:18:33 +02:00
|
|
|
|
|
|
|
handler_rkey_mode:
|
2001-11-05 23:05:45 +01:00
|
|
|
EQ { $$=HA_READ_KEY_EXACT; }
|
|
|
|
| GE { $$=HA_READ_KEY_OR_NEXT; }
|
|
|
|
| LE { $$=HA_READ_KEY_OR_PREV; }
|
|
|
|
| GT_SYM { $$=HA_READ_AFTER_KEY; }
|
2002-10-16 15:55:08 +02:00
|
|
|
| LT { $$=HA_READ_BEFORE_KEY; }
|
|
|
|
;
|
2001-04-07 00:18:33 +02:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
/* GRANT / REVOKE */
|
|
|
|
|
|
|
|
revoke:
|
2004-11-25 21:55:49 +01:00
|
|
|
REVOKE clear_privileges revoke_command
|
2003-06-06 14:43:23 +02:00
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
|
|
|
revoke_command:
|
2005-05-17 20:54:20 +02:00
|
|
|
grant_privileges ON opt_table grant_ident FROM grant_list
|
2004-11-25 21:55:49 +01:00
|
|
|
{
|
2005-05-17 20:54:20 +02:00
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command= SQLCOM_REVOKE;
|
|
|
|
lex->type= 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
grant_privileges ON FUNCTION_SYM grant_ident FROM grant_list
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
if (lex->columns.elements)
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2005-05-17 20:54:20 +02:00
|
|
|
}
|
|
|
|
lex->sql_command= SQLCOM_REVOKE;
|
|
|
|
lex->type= TYPE_ENUM_FUNCTION;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
grant_privileges ON PROCEDURE grant_ident FROM grant_list
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
if (lex->columns.elements)
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2005-05-17 20:54:20 +02:00
|
|
|
}
|
|
|
|
lex->sql_command= SQLCOM_REVOKE;
|
|
|
|
lex->type= TYPE_ENUM_PROCEDURE;
|
2004-11-25 21:55:49 +01:00
|
|
|
}
|
2003-06-06 14:43:23 +02:00
|
|
|
|
|
2004-11-25 21:55:49 +01:00
|
|
|
ALL opt_privileges ',' GRANT OPTION FROM grant_list
|
2003-06-06 14:43:23 +02:00
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_REVOKE_ALL;
|
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
grant:
|
2005-05-17 20:54:20 +02:00
|
|
|
GRANT clear_privileges grant_command
|
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
|
|
|
grant_command:
|
|
|
|
grant_privileges ON opt_table grant_ident TO_SYM grant_list
|
2002-11-28 18:57:56 +01:00
|
|
|
require_clause grant_options
|
2005-05-17 20:54:20 +02:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command= SQLCOM_GRANT;
|
|
|
|
lex->type= 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
grant_privileges ON FUNCTION_SYM grant_ident TO_SYM grant_list
|
|
|
|
require_clause grant_options
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
if (lex->columns.elements)
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2005-05-17 20:54:20 +02:00
|
|
|
}
|
|
|
|
lex->sql_command= SQLCOM_GRANT;
|
|
|
|
lex->type= TYPE_ENUM_FUNCTION;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
grant_privileges ON PROCEDURE grant_ident TO_SYM grant_list
|
|
|
|
require_clause grant_options
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
if (lex->columns.elements)
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2005-05-17 20:54:20 +02:00
|
|
|
}
|
|
|
|
lex->sql_command= SQLCOM_GRANT;
|
|
|
|
lex->type= TYPE_ENUM_PROCEDURE;
|
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-05-17 20:54:20 +02:00
|
|
|
opt_table:
|
|
|
|
/* Empty */
|
|
|
|
| TABLE_SYM ;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
grant_privileges:
|
2004-12-23 11:46:24 +01:00
|
|
|
object_privilege_list { }
|
|
|
|
| ALL opt_privileges
|
|
|
|
{
|
|
|
|
Lex->all_privileges= 1;
|
|
|
|
Lex->grant= GLOBAL_ACLS;
|
|
|
|
}
|
2002-10-16 15:55:08 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2004-11-10 19:53:16 +01:00
|
|
|
opt_privileges:
|
|
|
|
/* empty */
|
|
|
|
| PRIVILEGES
|
|
|
|
;
|
|
|
|
|
2004-12-23 11:46:24 +01:00
|
|
|
object_privilege_list:
|
|
|
|
object_privilege
|
|
|
|
| object_privilege_list ',' object_privilege;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2004-12-23 11:46:24 +01:00
|
|
|
object_privilege:
|
2003-08-05 21:14:15 +02:00
|
|
|
SELECT_SYM { Lex->which_columns = SELECT_ACL;} opt_column_list {}
|
2002-11-28 18:57:56 +01:00
|
|
|
| INSERT { Lex->which_columns = INSERT_ACL;} opt_column_list {}
|
|
|
|
| UPDATE_SYM { Lex->which_columns = UPDATE_ACL; } opt_column_list {}
|
|
|
|
| REFERENCES { Lex->which_columns = REFERENCES_ACL;} opt_column_list {}
|
2002-06-12 14:04:18 +02:00
|
|
|
| DELETE_SYM { Lex->grant |= DELETE_ACL;}
|
|
|
|
| USAGE {}
|
2004-06-23 12:29:05 +02:00
|
|
|
| INDEX_SYM { Lex->grant |= INDEX_ACL;}
|
2000-07-31 21:29:14 +02:00
|
|
|
| ALTER { Lex->grant |= ALTER_ACL;}
|
|
|
|
| CREATE { Lex->grant |= CREATE_ACL;}
|
|
|
|
| DROP { Lex->grant |= DROP_ACL;}
|
2002-06-12 14:04:18 +02:00
|
|
|
| EXECUTE_SYM { Lex->grant |= EXECUTE_ACL;}
|
2000-07-31 21:29:14 +02:00
|
|
|
| RELOAD { Lex->grant |= RELOAD_ACL;}
|
|
|
|
| SHUTDOWN { Lex->grant |= SHUTDOWN_ACL;}
|
|
|
|
| PROCESS { Lex->grant |= PROCESS_ACL;}
|
|
|
|
| FILE_SYM { Lex->grant |= FILE_ACL;}
|
2002-06-12 14:04:18 +02:00
|
|
|
| GRANT OPTION { Lex->grant |= GRANT_ACL;}
|
|
|
|
| SHOW DATABASES { Lex->grant |= SHOW_DB_ACL;}
|
|
|
|
| SUPER_SYM { Lex->grant |= SUPER_ACL;}
|
|
|
|
| CREATE TEMPORARY TABLES { Lex->grant |= CREATE_TMP_ACL;}
|
|
|
|
| LOCK_SYM TABLES { Lex->grant |= LOCK_TABLES_ACL; }
|
2004-11-12 04:01:46 +01:00
|
|
|
| REPLICATION SLAVE { Lex->grant |= REPL_SLAVE_ACL; }
|
|
|
|
| REPLICATION CLIENT_SYM { Lex->grant |= REPL_CLIENT_ACL; }
|
|
|
|
| CREATE VIEW_SYM { Lex->grant |= CREATE_VIEW_ACL; }
|
|
|
|
| SHOW VIEW_SYM { Lex->grant |= SHOW_VIEW_ACL; }
|
2004-12-23 11:46:24 +01:00
|
|
|
| CREATE ROUTINE_SYM { Lex->grant |= CREATE_PROC_ACL; }
|
|
|
|
| ALTER ROUTINE_SYM { Lex->grant |= ALTER_PROC_ACL; }
|
2005-03-22 15:54:18 +01:00
|
|
|
| CREATE USER { Lex->grant |= CREATE_USER_ACL; }
|
2005-12-02 13:07:02 +01:00
|
|
|
| EVENT_SYM { Lex->grant |= EVENT_ACL;}
|
2006-02-01 11:28:45 +01:00
|
|
|
| TRIGGER_SYM { Lex->grant |= TRIGGER_ACL; }
|
2002-06-12 14:04:18 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-09-20 03:45:13 +02:00
|
|
|
|
2002-09-05 15:17:08 +02:00
|
|
|
opt_and:
|
|
|
|
/* empty */ {}
|
2004-04-15 09:14:14 +02:00
|
|
|
| AND_SYM {}
|
2002-09-05 15:17:08 +02:00
|
|
|
;
|
|
|
|
|
|
|
|
require_list:
|
|
|
|
require_list_element opt_and require_list
|
|
|
|
| require_list_element
|
|
|
|
;
|
|
|
|
|
|
|
|
require_list_element:
|
|
|
|
SUBJECT_SYM TEXT_STRING
|
2002-06-12 14:04:18 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
if (lex->x509_subject)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_DUP_ARGUMENT, MYF(0), "SUBJECT");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-06-12 14:04:18 +02:00
|
|
|
}
|
|
|
|
lex->x509_subject=$2.str;
|
|
|
|
}
|
|
|
|
| ISSUER_SYM TEXT_STRING
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
if (lex->x509_issuer)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_DUP_ARGUMENT, MYF(0), "ISSUER");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-06-12 14:04:18 +02:00
|
|
|
}
|
|
|
|
lex->x509_issuer=$2.str;
|
|
|
|
}
|
|
|
|
| CIPHER_SYM TEXT_STRING
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
if (lex->ssl_cipher)
|
|
|
|
{
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_DUP_ARGUMENT, MYF(0), "CIPHER");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-06-12 14:04:18 +02:00
|
|
|
}
|
|
|
|
lex->ssl_cipher=$2.str;
|
|
|
|
}
|
|
|
|
;
|
2002-12-04 23:14:51 +01:00
|
|
|
|
2005-05-17 20:54:20 +02:00
|
|
|
grant_ident:
|
2000-07-31 21:29:14 +02:00
|
|
|
'*'
|
|
|
|
{
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX *lex= Lex;
|
WL#3817: Simplify string / memory area types and make things more consistent (first part)
The following type conversions was done:
- Changed byte to uchar
- Changed gptr to uchar*
- Change my_string to char *
- Change my_size_t to size_t
- Change size_s to size_t
Removed declaration of byte, gptr, my_string, my_size_t and size_s.
Following function parameter changes was done:
- All string functions in mysys/strings was changed to use size_t
instead of uint for string lengths.
- All read()/write() functions changed to use size_t (including vio).
- All protocoll functions changed to use size_t instead of uint
- Functions that used a pointer to a string length was changed to use size_t*
- Changed malloc(), free() and related functions from using gptr to use void *
as this requires fewer casts in the code and is more in line with how the
standard functions work.
- Added extra length argument to dirname_part() to return the length of the
created string.
- Changed (at least) following functions to take uchar* as argument:
- db_dump()
- my_net_write()
- net_write_command()
- net_store_data()
- DBUG_DUMP()
- decimal2bin() & bin2decimal()
- Changed my_compress() and my_uncompress() to use size_t. Changed one
argument to my_uncompress() from a pointer to a value as we only return
one value (makes function easier to use).
- Changed type of 'pack_data' argument to packfrm() to avoid casts.
- Changed in readfrm() and writefrom(), ha_discover and handler::discover()
the type for argument 'frmdata' to uchar** to avoid casts.
- Changed most Field functions to use uchar* instead of char* (reduced a lot of
casts).
- Changed field->val_xxx(xxx, new_ptr) to take const pointers.
Other changes:
- Removed a lot of not needed casts
- Added a few new cast required by other changes
- Added some cast to my_multi_malloc() arguments for safety (as string lengths
needs to be uint, not size_t).
- Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
explicitely as this conflict was often hided by casting the function to
hash_get_key).
- Changed some buffers to memory regions to uchar* to avoid casts.
- Changed some string lengths from uint to size_t.
- Changed field->ptr to be uchar* instead of char*. This allowed us to
get rid of a lot of casts.
- Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
- Include zlib.h in some files as we needed declaration of crc32()
- Changed MY_FILE_ERROR to be (size_t) -1.
- Changed many variables to hold the result of my_read() / my_write() to be
size_t. This was needed to properly detect errors (which are
returned as (size_t) -1).
- Removed some very old VMS code
- Changed packfrm()/unpackfrm() to not be depending on uint size
(portability fix)
- Removed windows specific code to restore cursor position as this
causes slowdown on windows and we should not mix read() and pread()
calls anyway as this is not thread safe. Updated function comment to
reflect this. Changed function that depended on original behavior of
my_pwrite() to itself restore the cursor position (one such case).
- Added some missing checking of return value of malloc().
- Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
- Changed type of table_def::m_size from my_size_t to ulong to reflect that
m_size is the number of elements in the array, not a string/memory
length.
- Moved THD::max_row_length() to table.cc (as it's not depending on THD).
Inlined max_row_length_blob() into this function.
- More function comments
- Fixed some compiler warnings when compiled without partitions.
- Removed setting of LEX_STRING() arguments in declaration (portability fix).
- Some trivial indentation/variable name changes.
- Some trivial code simplifications:
- Replaced some calls to alloc_root + memcpy to use
strmake_root()/strdup_root().
- Changed some calls from memdup() to strmake() (Safety fix)
- Simpler loops in client-simple.c
2007-05-10 11:59:39 +02:00
|
|
|
size_t dummy;
|
2007-07-16 21:31:36 +02:00
|
|
|
if (lex->copy_db_to(&lex->current_select->db, &dummy))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-06-12 14:04:18 +02:00
|
|
|
if (lex->grant == GLOBAL_ACLS)
|
2001-06-15 04:03:15 +02:00
|
|
|
lex->grant = DB_ACLS & ~GRANT_ACL;
|
|
|
|
else if (lex->columns.elements)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-11-12 13:34:00 +01:00
|
|
|
my_message(ER_ILLEGAL_GRANT_FOR_TABLE,
|
|
|
|
ER(ER_ILLEGAL_GRANT_FOR_TABLE), MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2001-06-15 04:03:15 +02:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
| ident '.' '*'
|
|
|
|
{
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX *lex= Lex;
|
2003-07-03 01:30:52 +02:00
|
|
|
lex->current_select->db = $1.str;
|
2002-06-12 14:04:18 +02:00
|
|
|
if (lex->grant == GLOBAL_ACLS)
|
2001-06-15 04:03:15 +02:00
|
|
|
lex->grant = DB_ACLS & ~GRANT_ACL;
|
|
|
|
else if (lex->columns.elements)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-11-12 13:34:00 +01:00
|
|
|
my_message(ER_ILLEGAL_GRANT_FOR_TABLE,
|
|
|
|
ER(ER_ILLEGAL_GRANT_FOR_TABLE), MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
| '*' '.' '*'
|
|
|
|
{
|
2002-10-30 12:18:52 +01:00
|
|
|
LEX *lex= Lex;
|
2003-07-03 01:30:52 +02:00
|
|
|
lex->current_select->db = NULL;
|
2002-06-12 14:04:18 +02:00
|
|
|
if (lex->grant == GLOBAL_ACLS)
|
|
|
|
lex->grant= GLOBAL_ACLS & ~GRANT_ACL;
|
2001-06-15 04:03:15 +02:00
|
|
|
else if (lex->columns.elements)
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2004-11-12 13:34:00 +01:00
|
|
|
my_message(ER_ILLEGAL_GRANT_FOR_TABLE,
|
|
|
|
ER(ER_ILLEGAL_GRANT_FOR_TABLE), MYF(0));
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
| table_ident
|
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
2007-03-29 14:12:32 +02:00
|
|
|
if (!lex->current_select->add_table_to_list(lex->thd, $1,NULL,
|
|
|
|
TL_OPTION_UPDATING))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-06-12 14:04:18 +02:00
|
|
|
if (lex->grant == GLOBAL_ACLS)
|
2001-06-15 04:03:15 +02:00
|
|
|
lex->grant = TABLE_ACLS & ~GRANT_ACL;
|
2002-10-16 15:55:08 +02:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
user_list:
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
user { if (Lex->users_list.push_back($1)) MYSQL_YYABORT;}
|
2004-11-25 21:55:49 +01:00
|
|
|
| user_list ',' user
|
|
|
|
{
|
|
|
|
if (Lex->users_list.push_back($3))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2004-11-25 21:55:49 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
grant_list:
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
grant_user { if (Lex->users_list.push_back($1)) MYSQL_YYABORT;}
|
2004-11-25 21:55:49 +01:00
|
|
|
| grant_list ',' grant_user
|
2002-07-24 18:55:08 +02:00
|
|
|
{
|
|
|
|
if (Lex->users_list.push_back($3))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-07-24 18:55:08 +02:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
grant_user:
|
|
|
|
user IDENTIFIED_SYM BY TEXT_STRING
|
|
|
|
{
|
|
|
|
$$=$1; $1->password=$4;
|
|
|
|
if ($4.length)
|
|
|
|
{
|
2003-07-08 00:36:14 +02:00
|
|
|
if (YYTHD->variables.old_passwords)
|
2003-07-01 21:40:59 +02:00
|
|
|
{
|
|
|
|
char *buff=
|
|
|
|
(char *) YYTHD->alloc(SCRAMBLED_PASSWORD_CHAR_LENGTH_323+1);
|
|
|
|
if (buff)
|
|
|
|
make_scrambled_password_323(buff, $4.str);
|
|
|
|
$1->password.str= buff;
|
|
|
|
$1->password.length= SCRAMBLED_PASSWORD_CHAR_LENGTH_323;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
char *buff=
|
|
|
|
(char *) YYTHD->alloc(SCRAMBLED_PASSWORD_CHAR_LENGTH+1);
|
|
|
|
if (buff)
|
|
|
|
make_scrambled_password(buff, $4.str);
|
|
|
|
$1->password.str= buff;
|
|
|
|
$1->password.length= SCRAMBLED_PASSWORD_CHAR_LENGTH;
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
| user IDENTIFIED_SYM BY PASSWORD TEXT_STRING
|
2005-01-16 13:16:23 +01:00
|
|
|
{ $$= $1; $1->password= $5; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| user
|
2005-01-16 13:16:23 +01:00
|
|
|
{ $$= $1; $1->password= null_lex_str; }
|
2002-10-16 15:55:08 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
opt_column_list:
|
2001-06-15 04:03:15 +02:00
|
|
|
/* empty */
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->grant |= lex->which_columns;
|
|
|
|
}
|
2002-04-16 01:09:30 +02:00
|
|
|
| '(' column_list ')';
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
column_list:
|
|
|
|
column_list ',' column_list_id
|
2002-04-16 01:09:30 +02:00
|
|
|
| column_list_id;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
column_list_id:
|
|
|
|
ident
|
|
|
|
{
|
2004-11-08 00:13:54 +01:00
|
|
|
String *new_str = new (YYTHD->mem_root) String((const char*) $1.str,$1.length,system_charset_info);
|
2000-07-31 21:29:14 +02:00
|
|
|
List_iterator <LEX_COLUMN> iter(Lex->columns);
|
|
|
|
class LEX_COLUMN *point;
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
2000-07-31 21:29:14 +02:00
|
|
|
while ((point=iter++))
|
|
|
|
{
|
2002-03-12 18:37:58 +01:00
|
|
|
if (!my_strcasecmp(system_charset_info,
|
|
|
|
point->column.ptr(), new_str->ptr()))
|
2000-07-31 21:29:14 +02:00
|
|
|
break;
|
|
|
|
}
|
2001-06-15 04:03:15 +02:00
|
|
|
lex->grant_tot_col|= lex->which_columns;
|
2000-07-31 21:29:14 +02:00
|
|
|
if (point)
|
2001-06-15 04:03:15 +02:00
|
|
|
point->rights |= lex->which_columns;
|
2000-07-31 21:29:14 +02:00
|
|
|
else
|
2001-06-15 04:03:15 +02:00
|
|
|
lex->columns.push_back(new LEX_COLUMN (*new_str,lex->which_columns));
|
2002-10-16 15:55:08 +02:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-09-01 10:29:37 +02:00
|
|
|
|
|
|
|
require_clause: /* empty */
|
2002-12-04 23:14:51 +01:00
|
|
|
| REQUIRE_SYM require_list
|
2002-09-05 15:17:08 +02:00
|
|
|
{
|
|
|
|
Lex->ssl_type=SSL_TYPE_SPECIFIED;
|
|
|
|
}
|
2001-09-30 04:46:20 +02:00
|
|
|
| REQUIRE_SYM SSL_SYM
|
2002-09-05 15:17:08 +02:00
|
|
|
{
|
|
|
|
Lex->ssl_type=SSL_TYPE_ANY;
|
|
|
|
}
|
2001-09-30 04:46:20 +02:00
|
|
|
| REQUIRE_SYM X509_SYM
|
2002-09-05 15:17:08 +02:00
|
|
|
{
|
|
|
|
Lex->ssl_type=SSL_TYPE_X509;
|
|
|
|
}
|
|
|
|
| REQUIRE_SYM NONE_SYM
|
|
|
|
{
|
|
|
|
Lex->ssl_type=SSL_TYPE_NONE;
|
|
|
|
}
|
2002-10-16 15:55:08 +02:00
|
|
|
;
|
2001-09-01 10:29:37 +02:00
|
|
|
|
2002-01-29 17:32:16 +01:00
|
|
|
grant_options:
|
2000-07-31 21:29:14 +02:00
|
|
|
/* empty */ {}
|
2002-04-16 01:09:30 +02:00
|
|
|
| WITH grant_option_list;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2002-01-29 17:32:16 +01:00
|
|
|
grant_option_list:
|
|
|
|
grant_option_list grant_option {}
|
2002-10-16 15:55:08 +02:00
|
|
|
| grant_option {}
|
|
|
|
;
|
2002-01-29 17:32:16 +01:00
|
|
|
|
|
|
|
grant_option:
|
|
|
|
GRANT OPTION { Lex->grant |= GRANT_ACL;}
|
2005-04-04 00:50:05 +02:00
|
|
|
| MAX_QUERIES_PER_HOUR ulong_num
|
2002-01-29 17:32:16 +01:00
|
|
|
{
|
2005-02-14 21:50:09 +01:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->mqh.questions=$2;
|
|
|
|
lex->mqh.specified_limits|= USER_RESOURCES::QUERIES_PER_HOUR;
|
2002-05-15 12:50:38 +02:00
|
|
|
}
|
2005-04-04 00:50:05 +02:00
|
|
|
| MAX_UPDATES_PER_HOUR ulong_num
|
2002-05-15 12:50:38 +02:00
|
|
|
{
|
2005-02-14 21:50:09 +01:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->mqh.updates=$2;
|
|
|
|
lex->mqh.specified_limits|= USER_RESOURCES::UPDATES_PER_HOUR;
|
2002-05-15 12:50:38 +02:00
|
|
|
}
|
2005-04-04 00:50:05 +02:00
|
|
|
| MAX_CONNECTIONS_PER_HOUR ulong_num
|
2002-05-15 12:50:38 +02:00
|
|
|
{
|
2005-02-14 21:50:09 +01:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->mqh.conn_per_hour= $2;
|
|
|
|
lex->mqh.specified_limits|= USER_RESOURCES::CONNECTIONS_PER_HOUR;
|
2002-10-16 15:55:08 +02:00
|
|
|
}
|
2005-04-04 00:50:05 +02:00
|
|
|
| MAX_USER_CONNECTIONS_SYM ulong_num
|
2004-12-29 18:30:37 +01:00
|
|
|
{
|
2005-02-14 21:50:09 +01:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->mqh.user_conn= $2;
|
|
|
|
lex->mqh.specified_limits|= USER_RESOURCES::USER_CONNECTIONS;
|
2002-10-16 15:55:08 +02:00
|
|
|
}
|
|
|
|
;
|
2001-12-26 15:49:10 +01:00
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
begin:
|
2005-02-14 21:50:09 +01:00
|
|
|
BEGIN_SYM
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command = SQLCOM_BEGIN;
|
|
|
|
lex->start_transaction_opt= 0;
|
|
|
|
}
|
|
|
|
opt_work {}
|
2002-11-28 18:57:56 +01:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
opt_work:
|
|
|
|
/* empty */ {}
|
2005-02-14 21:50:09 +01:00
|
|
|
| WORK_SYM {}
|
2002-10-16 15:55:08 +02:00
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-02-01 20:48:05 +01:00
|
|
|
opt_chain:
|
2005-02-14 21:50:09 +01:00
|
|
|
/* empty */ { $$= (YYTHD->variables.completion_type == 1); }
|
2005-02-01 20:48:05 +01:00
|
|
|
| AND_SYM NO_SYM CHAIN_SYM { $$=0; }
|
|
|
|
| AND_SYM CHAIN_SYM { $$=1; }
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_release:
|
2005-02-14 21:50:09 +01:00
|
|
|
/* empty */ { $$= (YYTHD->variables.completion_type == 2); }
|
2005-02-01 20:48:05 +01:00
|
|
|
| RELEASE_SYM { $$=1; }
|
|
|
|
| NO_SYM RELEASE_SYM { $$=0; }
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_savepoint:
|
|
|
|
/* empty */ {}
|
|
|
|
| SAVEPOINT_SYM {}
|
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
commit:
|
2005-02-14 21:50:09 +01:00
|
|
|
COMMIT_SYM opt_work opt_chain opt_release
|
2005-02-01 20:48:05 +01:00
|
|
|
{
|
2005-02-14 21:50:09 +01:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_COMMIT;
|
|
|
|
lex->tx_chain= $3;
|
|
|
|
lex->tx_release= $4;
|
2005-02-01 20:48:05 +01:00
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
rollback:
|
2005-02-14 21:50:09 +01:00
|
|
|
ROLLBACK_SYM opt_work opt_chain opt_release
|
2003-06-06 03:18:58 +02:00
|
|
|
{
|
2005-02-14 21:50:09 +01:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_ROLLBACK;
|
|
|
|
lex->tx_chain= $3;
|
|
|
|
lex->tx_release= $4;
|
2003-06-06 03:18:58 +02:00
|
|
|
}
|
2005-02-01 20:48:05 +01:00
|
|
|
| ROLLBACK_SYM opt_work
|
|
|
|
TO_SYM opt_savepoint ident
|
2003-06-06 03:18:58 +02:00
|
|
|
{
|
2005-02-14 21:50:09 +01:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_ROLLBACK_TO_SAVEPOINT;
|
|
|
|
lex->ident= $5;
|
2005-02-01 20:48:05 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2003-06-06 03:18:58 +02:00
|
|
|
savepoint:
|
|
|
|
SAVEPOINT_SYM ident
|
|
|
|
{
|
2005-02-14 21:50:09 +01:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_SAVEPOINT;
|
|
|
|
lex->ident= $2;
|
2005-02-01 20:48:05 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
release:
|
|
|
|
RELEASE_SYM SAVEPOINT_SYM ident
|
|
|
|
{
|
2005-02-14 21:50:09 +01:00
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_RELEASE_SAVEPOINT;
|
|
|
|
lex->ident= $3;
|
2005-02-01 20:48:05 +01:00
|
|
|
}
|
|
|
|
;
|
2005-02-14 21:50:09 +01:00
|
|
|
|
2001-06-13 12:36:53 +02:00
|
|
|
/*
|
2002-08-30 11:40:40 +02:00
|
|
|
UNIONS : glue selects together
|
2001-06-13 12:36:53 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
2002-11-28 17:25:41 +01:00
|
|
|
union_clause:
|
2002-07-24 18:55:08 +02:00
|
|
|
/* empty */ {}
|
2002-11-21 21:25:53 +01:00
|
|
|
| union_list
|
|
|
|
;
|
2001-06-13 12:36:53 +02:00
|
|
|
|
|
|
|
union_list:
|
2004-03-23 14:43:24 +01:00
|
|
|
UNION_SYM union_option
|
2002-07-24 18:55:08 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2007-03-21 19:54:38 +01:00
|
|
|
if (lex->result)
|
2002-07-24 18:55:08 +02:00
|
|
|
{
|
|
|
|
/* Only the last SELECT can have INTO...... */
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_WRONG_USAGE, MYF(0), "UNION", "INTO");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-12-04 23:14:51 +01:00
|
|
|
}
|
2002-10-30 12:18:52 +01:00
|
|
|
if (lex->current_select->linkage == GLOBAL_OPTIONS_TYPE)
|
2002-07-24 18:55:08 +02:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2002-07-24 18:55:08 +02:00
|
|
|
}
|
2006-06-15 20:09:58 +02:00
|
|
|
/* This counter shouldn't be incremented for UNION parts */
|
|
|
|
Lex->nest_level--;
|
2002-10-02 12:33:08 +02:00
|
|
|
if (mysql_new_select(lex, 0))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2003-02-13 16:56:01 +01:00
|
|
|
mysql_init_select(lex);
|
2002-10-30 12:18:52 +01:00
|
|
|
lex->current_select->linkage=UNION_TYPE;
|
2004-03-23 14:43:24 +01:00
|
|
|
if ($2) /* UNION DISTINCT - remember position */
|
|
|
|
lex->current_select->master_unit()->union_distinct=
|
|
|
|
lex->current_select;
|
2002-08-30 11:40:40 +02:00
|
|
|
}
|
2005-08-12 16:57:19 +02:00
|
|
|
select_init
|
|
|
|
{
|
2005-08-18 02:12:42 +02:00
|
|
|
/*
|
|
|
|
Remove from the name resolution context stack the context of the
|
|
|
|
last select in the union.
|
|
|
|
*/
|
2005-08-12 16:57:19 +02:00
|
|
|
Lex->pop_context();
|
|
|
|
}
|
2002-07-24 18:55:08 +02:00
|
|
|
;
|
2001-10-25 13:41:49 +02:00
|
|
|
|
|
|
|
union_opt:
|
2005-03-16 01:13:23 +01:00
|
|
|
/* Empty */ { $$= 0; }
|
|
|
|
| union_list { $$= 1; }
|
|
|
|
| union_order_or_limit { $$= 1; }
|
2002-11-21 21:25:53 +01:00
|
|
|
;
|
2001-10-19 16:43:30 +02:00
|
|
|
|
2005-03-16 01:13:23 +01:00
|
|
|
union_order_or_limit:
|
2002-07-24 18:55:08 +02:00
|
|
|
{
|
2003-01-14 17:00:34 +01:00
|
|
|
THD *thd= YYTHD;
|
2003-12-19 18:52:13 +01:00
|
|
|
LEX *lex= thd->lex;
|
2003-01-21 20:07:59 +01:00
|
|
|
DBUG_ASSERT(lex->current_select->linkage != GLOBAL_OPTIONS_TYPE);
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel= lex->current_select;
|
2003-03-07 20:47:04 +01:00
|
|
|
SELECT_LEX_UNIT *unit= sel->master_unit();
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *fake= unit->fake_select_lex;
|
2003-09-12 18:17:30 +02:00
|
|
|
if (fake)
|
|
|
|
{
|
|
|
|
unit->global_parameters= fake;
|
|
|
|
fake->no_table_names_allowed= 1;
|
|
|
|
lex->current_select= fake;
|
|
|
|
}
|
2003-01-14 17:00:34 +01:00
|
|
|
thd->where= "global ORDER clause";
|
2002-07-24 18:55:08 +02:00
|
|
|
}
|
2002-12-01 17:10:13 +01:00
|
|
|
order_or_limit
|
2003-01-14 17:00:34 +01:00
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
2003-12-19 18:52:13 +01:00
|
|
|
thd->lex->current_select->no_table_names_allowed= 0;
|
2003-01-14 17:00:34 +01:00
|
|
|
thd->where= "";
|
|
|
|
}
|
2002-12-01 17:10:13 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
order_or_limit:
|
2003-02-12 20:55:37 +01:00
|
|
|
order_clause opt_limit_clause_init
|
|
|
|
| limit_clause
|
2002-07-24 18:55:08 +02:00
|
|
|
;
|
2001-07-22 12:25:56 +02:00
|
|
|
|
|
|
|
union_option:
|
2004-03-23 14:43:24 +01:00
|
|
|
/* empty */ { $$=1; }
|
|
|
|
| DISTINCT { $$=1; }
|
|
|
|
| ALL { $$=0; }
|
|
|
|
;
|
2002-05-12 22:46:42 +02:00
|
|
|
|
2006-08-31 17:00:25 +02:00
|
|
|
subselect:
|
|
|
|
SELECT_SYM subselect_start subselect_init subselect_end
|
|
|
|
{
|
|
|
|
$$= $3;
|
|
|
|
}
|
|
|
|
| '(' subselect_start subselect ')'
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
/*
|
|
|
|
note that a local variable can't be used for
|
|
|
|
$3 as it's used in local variable construction
|
|
|
|
and some compilers can't guarnatee the order
|
|
|
|
in which the local variables are initialized.
|
|
|
|
*/
|
|
|
|
List_iterator<Item> it($3->item_list);
|
|
|
|
Item *item;
|
|
|
|
/*
|
|
|
|
we must fill the items list for the "derived table".
|
|
|
|
*/
|
|
|
|
while ((item= it++))
|
|
|
|
add_item_to_list(thd, item);
|
|
|
|
}
|
|
|
|
union_clause subselect_end { $$= $3; };
|
2002-10-27 22:27:00 +01:00
|
|
|
|
2006-08-31 17:00:25 +02:00
|
|
|
subselect_init:
|
2002-11-28 16:10:29 +01:00
|
|
|
select_init2
|
2002-10-27 22:27:00 +01:00
|
|
|
{
|
2002-11-05 10:59:18 +01:00
|
|
|
$$= Lex->current_select->master_unit()->first_select();
|
2002-10-27 22:27:00 +01:00
|
|
|
};
|
|
|
|
|
2002-05-12 22:46:42 +02:00
|
|
|
subselect_start:
|
2002-08-30 11:40:40 +02:00
|
|
|
{
|
2003-01-09 21:17:16 +01:00
|
|
|
LEX *lex=Lex;
|
2007-06-11 11:38:37 +02:00
|
|
|
if (!lex->expr_allows_subselect ||
|
|
|
|
lex->sql_command == (int)SQLCOM_PURGE)
|
2004-02-12 18:37:15 +01:00
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2003-01-09 21:17:16 +01:00
|
|
|
}
|
2006-08-31 17:00:25 +02:00
|
|
|
/*
|
|
|
|
we are making a "derived table" for the parenthesis
|
|
|
|
as we need to have a lex level to fit the union
|
|
|
|
after the parenthesis, e.g.
|
|
|
|
(SELECT .. ) UNION ... becomes
|
|
|
|
SELECT * FROM ((SELECT ...) UNION ...)
|
|
|
|
*/
|
2002-08-30 11:40:40 +02:00
|
|
|
if (mysql_new_select(Lex, 1))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2002-08-30 11:40:40 +02:00
|
|
|
};
|
2002-05-12 22:46:42 +02:00
|
|
|
|
|
|
|
subselect_end:
|
2002-08-30 11:40:40 +02:00
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2005-08-12 16:57:19 +02:00
|
|
|
lex->pop_context();
|
2006-09-01 11:23:43 +02:00
|
|
|
SELECT_LEX *child= lex->current_select;
|
2003-03-11 00:06:28 +01:00
|
|
|
lex->current_select = lex->current_select->return_after_parsing();
|
2005-10-15 23:32:37 +02:00
|
|
|
lex->nest_level--;
|
2006-09-01 11:23:43 +02:00
|
|
|
lex->current_select->n_child_sum_items += child->n_sum_items;
|
2007-02-24 21:04:15 +01:00
|
|
|
/*
|
|
|
|
A subselect can add fields to an outer select. Reserve space for
|
|
|
|
them.
|
|
|
|
*/
|
|
|
|
lex->current_select->select_n_where_fields+=
|
|
|
|
child->select_n_where_fields;
|
2002-10-11 20:49:10 +02:00
|
|
|
};
|
2003-08-05 21:14:15 +02:00
|
|
|
|
2006-03-02 13:18:49 +01:00
|
|
|
/**************************************************************************
|
|
|
|
|
|
|
|
CREATE VIEW | TRIGGER | PROCEDURE statements.
|
|
|
|
|
|
|
|
**************************************************************************/
|
|
|
|
|
2006-06-27 13:15:40 +02:00
|
|
|
view_or_trigger_or_sp_or_event:
|
|
|
|
definer view_or_trigger_or_sp_or_event_tail
|
2006-03-02 13:18:49 +01:00
|
|
|
{}
|
|
|
|
| view_replace_or_algorithm definer view_tail
|
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
2006-06-27 13:15:40 +02:00
|
|
|
view_or_trigger_or_sp_or_event_tail:
|
2006-03-02 13:18:49 +01:00
|
|
|
view_tail
|
|
|
|
{}
|
|
|
|
| trigger_tail
|
|
|
|
{}
|
|
|
|
| sp_tail
|
|
|
|
{}
|
2006-06-27 13:15:40 +02:00
|
|
|
| event_tail
|
|
|
|
{}
|
2006-03-02 13:18:49 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
/**************************************************************************
|
|
|
|
|
|
|
|
DEFINER clause support.
|
|
|
|
|
|
|
|
**************************************************************************/
|
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
definer:
|
2006-03-01 12:13:07 +01:00
|
|
|
/* empty */
|
2005-11-10 20:25:03 +01:00
|
|
|
{
|
2006-03-01 12:13:07 +01:00
|
|
|
/*
|
|
|
|
We have to distinguish missing DEFINER-clause from case when
|
|
|
|
CURRENT_USER specified as definer explicitly in order to properly
|
|
|
|
handle CREATE TRIGGER statements which come to replication thread
|
|
|
|
from older master servers (i.e. to create non-suid trigger in this
|
|
|
|
case).
|
|
|
|
*/
|
|
|
|
YYTHD->lex->definer= 0;
|
2005-11-10 20:25:03 +01:00
|
|
|
}
|
2006-08-23 19:31:00 +02:00
|
|
|
| DEFINER_SYM EQ user
|
2005-11-10 20:25:03 +01:00
|
|
|
{
|
2006-08-23 19:31:00 +02:00
|
|
|
YYTHD->lex->definer= get_current_user(YYTHD, $3);
|
2005-11-10 20:25:03 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
/**************************************************************************
|
|
|
|
|
2006-03-02 13:18:49 +01:00
|
|
|
CREATE VIEW statement parts.
|
2005-11-10 20:25:03 +01:00
|
|
|
|
|
|
|
**************************************************************************/
|
|
|
|
|
|
|
|
view_replace_or_algorithm:
|
|
|
|
view_replace
|
|
|
|
{}
|
|
|
|
| view_replace view_algorithm
|
|
|
|
{}
|
|
|
|
| view_algorithm
|
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
|
|
|
view_replace:
|
|
|
|
OR_SYM REPLACE
|
|
|
|
{ Lex->create_view_mode= VIEW_CREATE_OR_REPLACE; }
|
|
|
|
;
|
|
|
|
|
|
|
|
view_algorithm:
|
|
|
|
ALGORITHM_SYM EQ UNDEFINED_SYM
|
|
|
|
{ Lex->create_view_algorithm= VIEW_ALGORITHM_UNDEFINED; }
|
|
|
|
| ALGORITHM_SYM EQ MERGE_SYM
|
|
|
|
{ Lex->create_view_algorithm= VIEW_ALGORITHM_MERGE; }
|
|
|
|
| ALGORITHM_SYM EQ TEMPTABLE_SYM
|
|
|
|
{ Lex->create_view_algorithm= VIEW_ALGORITHM_TMPTABLE; }
|
|
|
|
;
|
|
|
|
|
|
|
|
view_suid:
|
|
|
|
/* empty */
|
2006-07-31 16:33:37 +02:00
|
|
|
{ Lex->create_view_suid= VIEW_SUID_DEFAULT; }
|
2005-11-10 20:25:03 +01:00
|
|
|
| SQL_SYM SECURITY_SYM DEFINER_SYM
|
2006-07-31 16:33:37 +02:00
|
|
|
{ Lex->create_view_suid= VIEW_SUID_DEFINER; }
|
2005-11-10 20:25:03 +01:00
|
|
|
| SQL_SYM SECURITY_SYM INVOKER_SYM
|
2006-07-31 16:33:37 +02:00
|
|
|
{ Lex->create_view_suid= VIEW_SUID_INVOKER; }
|
2005-11-10 20:25:03 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
view_tail:
|
|
|
|
view_suid VIEW_SYM table_ident
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
lex->sql_command= SQLCOM_CREATE_VIEW;
|
|
|
|
/* first table in list is target VIEW name */
|
2006-04-12 11:50:12 +02:00
|
|
|
if (!lex->select_lex.add_table_to_list(thd, $3, NULL, TL_OPTION_UPDATING))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-11-10 20:25:03 +01:00
|
|
|
}
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
view_list_opt AS
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
|
|
|
|
|
|
|
lip->body_utf8_start(thd, lip->get_cpp_ptr());
|
|
|
|
}
|
|
|
|
view_select
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
|
|
|
|
|
|
|
lip->body_utf8_append(lip->get_cpp_ptr());
|
|
|
|
|
|
|
|
lex->view_body_utf8.str= thd->strmake(lip->get_body_utf8_str(),
|
|
|
|
lip->get_body_utf8_length());
|
|
|
|
lex->view_body_utf8.length= lip->get_body_utf8_length();
|
|
|
|
|
|
|
|
trim_whitespace(&my_charset_utf8_general_ci, &lex->view_body_utf8);
|
|
|
|
}
|
2005-11-10 20:25:03 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
view_list_opt:
|
|
|
|
/* empty */
|
|
|
|
{}
|
2004-11-12 04:01:46 +01:00
|
|
|
| '(' view_list ')'
|
|
|
|
;
|
|
|
|
|
|
|
|
view_list:
|
|
|
|
ident
|
|
|
|
{
|
|
|
|
Lex->view_list.push_back((LEX_STRING*)
|
|
|
|
sql_memdup(&$1, sizeof(LEX_STRING)));
|
|
|
|
}
|
|
|
|
| view_list ',' ident
|
|
|
|
{
|
|
|
|
Lex->view_list.push_back((LEX_STRING*)
|
|
|
|
sql_memdup(&$3, sizeof(LEX_STRING)));
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
view_select:
|
2006-10-12 16:02:57 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
THD *thd= YYTHD;
|
2006-10-12 16:02:57 +02:00
|
|
|
LEX *lex= Lex;
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2006-10-12 16:02:57 +02:00
|
|
|
lex->parsing_options.allows_variable= FALSE;
|
|
|
|
lex->parsing_options.allows_select_into= FALSE;
|
|
|
|
lex->parsing_options.allows_select_procedure= FALSE;
|
|
|
|
lex->parsing_options.allows_derived= FALSE;
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
lex->create_view_select_start= lip->get_cpp_ptr();
|
|
|
|
}
|
|
|
|
view_select_aux view_check_option
|
2006-10-12 16:02:57 +02:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
THD *thd= YYTHD;
|
2006-10-12 16:02:57 +02:00
|
|
|
LEX *lex= Lex;
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2006-10-12 16:02:57 +02:00
|
|
|
lex->parsing_options.allows_variable= TRUE;
|
|
|
|
lex->parsing_options.allows_select_into= TRUE;
|
|
|
|
lex->parsing_options.allows_select_procedure= TRUE;
|
|
|
|
lex->parsing_options.allows_derived= TRUE;
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
lex->create_view_select_end= lip->get_cpp_ptr();
|
2006-10-12 16:02:57 +02:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
view_select_aux:
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
SELECT_SYM select_init2
|
|
|
|
| '(' select_paren ')' union_opt
|
|
|
|
;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
view_check_option:
|
2004-11-12 04:01:46 +01:00
|
|
|
/* empty */
|
2005-11-10 20:25:03 +01:00
|
|
|
{ Lex->create_view_check= VIEW_CHECK_NONE; }
|
|
|
|
| WITH CHECK_SYM OPTION
|
|
|
|
{ Lex->create_view_check= VIEW_CHECK_CASCADED; }
|
|
|
|
| WITH CASCADED CHECK_SYM OPTION
|
|
|
|
{ Lex->create_view_check= VIEW_CHECK_CASCADED; }
|
|
|
|
| WITH LOCAL_SYM CHECK_SYM OPTION
|
|
|
|
{ Lex->create_view_check= VIEW_CHECK_LOCAL; }
|
2004-11-12 04:01:46 +01:00
|
|
|
;
|
2005-09-14 09:53:09 +02:00
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
/**************************************************************************
|
|
|
|
|
|
|
|
CREATE TRIGGER statement parts.
|
|
|
|
|
|
|
|
**************************************************************************/
|
|
|
|
|
|
|
|
trigger_tail:
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
TRIGGER_SYM
|
|
|
|
remember_name
|
|
|
|
sp_name
|
|
|
|
trg_action_time
|
|
|
|
trg_event
|
|
|
|
ON
|
|
|
|
remember_name /* $7 */
|
|
|
|
{ /* $8 */
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
|
|
|
lex->raw_trg_on_table_name_begin= lip->get_tok_start();
|
|
|
|
}
|
|
|
|
table_ident /* $9 */
|
|
|
|
FOR_SYM
|
|
|
|
remember_name /* $11 */
|
|
|
|
{ /* $12 */
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
|
|
|
lex->raw_trg_on_table_name_end= lip->get_tok_start();
|
|
|
|
}
|
|
|
|
EACH_SYM
|
|
|
|
ROW_SYM
|
|
|
|
{ /* $15 */
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2005-11-10 20:25:03 +01:00
|
|
|
sp_head *sp;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
if (lex->sphead)
|
2005-09-14 09:53:09 +02:00
|
|
|
{
|
2005-11-10 20:25:03 +01:00
|
|
|
my_error(ER_SP_NO_RECURSIVE_CREATE, MYF(0), "TRIGGER");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-09-14 09:53:09 +02:00
|
|
|
}
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
if (!(sp= new sp_head()))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2007-04-26 05:38:12 +02:00
|
|
|
sp->reset_thd_mem_root(thd);
|
2005-11-10 20:25:03 +01:00
|
|
|
sp->init(lex);
|
A fix and a test case for Bug#26141 mixing table types in trigger
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.
2007-07-12 20:26:41 +02:00
|
|
|
sp->m_type= TYPE_ENUM_TRIGGER;
|
2007-04-26 05:38:12 +02:00
|
|
|
sp->init_sp_name(thd, $3);
|
2006-03-02 13:18:49 +01:00
|
|
|
lex->stmt_definition_begin= $2;
|
2006-02-24 21:50:36 +01:00
|
|
|
lex->ident.str= $7;
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
lex->ident.length= $11 - $7;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
lex->sphead= sp;
|
|
|
|
lex->spname= $3;
|
|
|
|
/*
|
|
|
|
We have to turn of CLIENT_MULTI_QUERIES while parsing a
|
|
|
|
stored procedure, otherwise yylex will chop it into pieces
|
|
|
|
at each ';'.
|
|
|
|
*/
|
2007-04-26 05:38:12 +02:00
|
|
|
$<ulong_num>$= thd->client_capabilities & CLIENT_MULTI_QUERIES;
|
|
|
|
thd->client_capabilities &= ~CLIENT_MULTI_QUERIES;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
bzero((char *)&lex->sp_chistics, sizeof(st_sp_chistics));
|
|
|
|
lex->sphead->m_chistics= &lex->sp_chistics;
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
lex->sphead->set_body_start(thd, lip->get_cpp_ptr());
|
2005-11-10 20:25:03 +01:00
|
|
|
}
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
sp_proc_stmt /* $16 */
|
|
|
|
{ /* $17 */
|
2005-11-10 20:25:03 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
lex->sql_command= SQLCOM_CREATE_TRIGGER;
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
sp->set_stmt_end(YYTHD);
|
2005-11-10 20:25:03 +01:00
|
|
|
/* Restore flag if it was cleared above */
|
2005-12-05 11:45:04 +01:00
|
|
|
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
YYTHD->client_capabilities |= $<ulong_num>15;
|
2005-11-10 20:25:03 +01:00
|
|
|
sp->restore_thd_mem_root(YYTHD);
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
if (sp->is_not_allowed_in_function("trigger"))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-02-14 13:19:54 +01:00
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
/*
|
|
|
|
We have to do it after parsing trigger body, because some of
|
|
|
|
sp_proc_stmt alternatives are not saving/restoring LEX, so
|
|
|
|
lex->query_tables can be wiped out.
|
|
|
|
*/
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
if (!lex->select_lex.add_table_to_list(YYTHD, $9,
|
2005-11-10 20:25:03 +01:00
|
|
|
(LEX_STRING*) 0,
|
|
|
|
TL_OPTION_UPDATING,
|
2006-02-24 21:50:36 +01:00
|
|
|
TL_IGNORE))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-11-10 20:25:03 +01:00
|
|
|
}
|
2005-09-14 09:53:09 +02:00
|
|
|
;
|
|
|
|
|
2006-03-02 13:18:49 +01:00
|
|
|
/**************************************************************************
|
|
|
|
|
|
|
|
CREATE FUNCTION | PROCEDURE statements parts.
|
|
|
|
|
|
|
|
**************************************************************************/
|
|
|
|
|
|
|
|
sp_tail:
|
|
|
|
udf_func_type remember_name FUNCTION_SYM sp_name
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->udf.type= $1;
|
|
|
|
lex->stmt_definition_begin= $2;
|
|
|
|
lex->spname= $4;
|
|
|
|
}
|
|
|
|
create_function_tail
|
|
|
|
{}
|
|
|
|
| PROCEDURE remember_name sp_name
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp;
|
|
|
|
|
|
|
|
if (lex->sphead)
|
|
|
|
{
|
|
|
|
my_error(ER_SP_NO_RECURSIVE_CREATE, MYF(0), "PROCEDURE");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2006-03-02 13:18:49 +01:00
|
|
|
}
|
2006-07-27 15:57:43 +02:00
|
|
|
|
2006-03-02 13:18:49 +01:00
|
|
|
lex->stmt_definition_begin= $2;
|
2006-07-27 15:57:43 +02:00
|
|
|
|
2006-03-02 13:18:49 +01:00
|
|
|
/* Order is important here: new - reset - init */
|
|
|
|
sp= new sp_head();
|
|
|
|
sp->reset_thd_mem_root(YYTHD);
|
|
|
|
sp->init(lex);
|
A fix and a test case for Bug#26141 mixing table types in trigger
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.
2007-07-12 20:26:41 +02:00
|
|
|
sp->m_type= TYPE_ENUM_PROCEDURE;
|
2006-07-27 15:57:43 +02:00
|
|
|
sp->init_sp_name(YYTHD, $3);
|
2006-03-02 13:18:49 +01:00
|
|
|
|
|
|
|
lex->sphead= sp;
|
|
|
|
/*
|
|
|
|
* We have to turn of CLIENT_MULTI_QUERIES while parsing a
|
|
|
|
* stored procedure, otherwise yylex will chop it into pieces
|
|
|
|
* at each ';'.
|
|
|
|
*/
|
2006-03-09 18:41:21 +01:00
|
|
|
$<ulong_num>$= YYTHD->client_capabilities & CLIENT_MULTI_QUERIES;
|
2006-03-02 13:18:49 +01:00
|
|
|
YYTHD->client_capabilities &= (~CLIENT_MULTI_QUERIES);
|
|
|
|
}
|
|
|
|
'('
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
const char* tmp_param_begin;
|
2006-03-02 13:18:49 +01:00
|
|
|
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
tmp_param_begin= lip->get_cpp_tok_start();
|
|
|
|
tmp_param_begin++;
|
|
|
|
lex->sphead->m_param_begin= tmp_param_begin;
|
2006-03-02 13:18:49 +01:00
|
|
|
}
|
|
|
|
sp_pdparam_list
|
|
|
|
')'
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2006-03-02 13:18:49 +01:00
|
|
|
|
Bug#25411 (trigger code truncated), PART II
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.
2007-06-12 23:23:58 +02:00
|
|
|
lex->sphead->m_param_end= lip->get_cpp_tok_start();
|
2006-03-02 13:18:49 +01:00
|
|
|
bzero((char *)&lex->sp_chistics, sizeof(st_sp_chistics));
|
|
|
|
}
|
|
|
|
sp_c_chistics
|
|
|
|
{
|
2007-04-26 05:38:12 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
2006-03-02 13:18:49 +01:00
|
|
|
|
|
|
|
lex->sphead->m_chistics= &lex->sp_chistics;
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
lex->sphead->set_body_start(thd, lip->get_cpp_tok_start());
|
2006-03-02 13:18:49 +01:00
|
|
|
}
|
|
|
|
sp_proc_stmt
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
|
Patch for the following bugs:
- 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;
2007-06-28 19:34:54 +02:00
|
|
|
sp->set_stmt_end(YYTHD);
|
2006-03-02 13:18:49 +01:00
|
|
|
lex->sql_command= SQLCOM_CREATE_PROCEDURE;
|
2006-03-09 18:41:21 +01:00
|
|
|
/*
|
|
|
|
Restore flag if it was cleared above
|
|
|
|
Be careful with counting. the block where we save the value
|
|
|
|
is $4.
|
|
|
|
*/
|
|
|
|
YYTHD->client_capabilities |= $<ulong_num>4;
|
2006-03-02 13:18:49 +01:00
|
|
|
sp->restore_thd_mem_root(YYTHD);
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2005-11-10 20:25:03 +01:00
|
|
|
/*************************************************************************/
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2005-01-16 13:16:23 +01:00
|
|
|
xa: XA_SYM begin_or_start xid opt_join_or_resume
|
|
|
|
{
|
2005-04-04 00:50:05 +02:00
|
|
|
Lex->sql_command = SQLCOM_XA_START;
|
2005-01-16 13:16:23 +01:00
|
|
|
}
|
2005-08-19 16:00:16 +02:00
|
|
|
| XA_SYM END xid opt_suspend
|
2005-01-16 13:16:23 +01:00
|
|
|
{
|
2005-04-04 00:50:05 +02:00
|
|
|
Lex->sql_command = SQLCOM_XA_END;
|
2005-01-16 13:16:23 +01:00
|
|
|
}
|
|
|
|
| XA_SYM PREPARE_SYM xid
|
|
|
|
{
|
2005-04-04 00:50:05 +02:00
|
|
|
Lex->sql_command = SQLCOM_XA_PREPARE;
|
2005-01-16 13:16:23 +01:00
|
|
|
}
|
|
|
|
| XA_SYM COMMIT_SYM xid opt_one_phase
|
|
|
|
{
|
2005-04-04 00:50:05 +02:00
|
|
|
Lex->sql_command = SQLCOM_XA_COMMIT;
|
2005-01-16 13:16:23 +01:00
|
|
|
}
|
|
|
|
| XA_SYM ROLLBACK_SYM xid
|
|
|
|
{
|
2005-04-04 00:50:05 +02:00
|
|
|
Lex->sql_command = SQLCOM_XA_ROLLBACK;
|
2005-01-16 13:16:23 +01:00
|
|
|
}
|
|
|
|
| XA_SYM RECOVER_SYM
|
|
|
|
{
|
2005-04-04 00:50:05 +02:00
|
|
|
Lex->sql_command = SQLCOM_XA_RECOVER;
|
2005-01-16 13:16:23 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2005-04-04 00:50:05 +02:00
|
|
|
xid: text_string
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1->length() <= MAXGTRIDSIZE);
|
2005-04-04 00:50:05 +02:00
|
|
|
if (!(Lex->xid=(XID *)YYTHD->alloc(sizeof(XID))))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-04-04 00:50:05 +02:00
|
|
|
Lex->xid->set(1L, $1->ptr(), $1->length(), 0, 0);
|
|
|
|
}
|
|
|
|
| text_string ',' text_string
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1->length() <= MAXGTRIDSIZE && $3->length() <= MAXBQUALSIZE);
|
2005-04-04 00:50:05 +02:00
|
|
|
if (!(Lex->xid=(XID *)YYTHD->alloc(sizeof(XID))))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-04-04 00:50:05 +02:00
|
|
|
Lex->xid->set(1L, $1->ptr(), $1->length(), $3->ptr(), $3->length());
|
|
|
|
}
|
|
|
|
| text_string ',' text_string ',' ulong_num
|
|
|
|
{
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT_UNLESS($1->length() <= MAXGTRIDSIZE && $3->length() <= MAXBQUALSIZE);
|
2005-04-04 00:50:05 +02:00
|
|
|
if (!(Lex->xid=(XID *)YYTHD->alloc(sizeof(XID))))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
2007-03-07 10:24:46 +01:00
|
|
|
MYSQL_YYABORT;
|
2005-04-04 00:50:05 +02:00
|
|
|
Lex->xid->set($5, $1->ptr(), $1->length(), $3->ptr(), $3->length());
|
|
|
|
}
|
|
|
|
;
|
2005-01-16 13:16:23 +01:00
|
|
|
|
|
|
|
begin_or_start: BEGIN_SYM {}
|
|
|
|
| START_SYM {}
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_join_or_resume:
|
|
|
|
/* nothing */ { Lex->xa_opt=XA_NONE; }
|
|
|
|
| JOIN_SYM { Lex->xa_opt=XA_JOIN; }
|
|
|
|
| RESUME_SYM { Lex->xa_opt=XA_RESUME; }
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_one_phase:
|
|
|
|
/* nothing */ { Lex->xa_opt=XA_NONE; }
|
|
|
|
| ONE_SYM PHASE_SYM { Lex->xa_opt=XA_ONE_PHASE; }
|
|
|
|
;
|
|
|
|
|
2005-08-19 16:00:16 +02:00
|
|
|
opt_suspend:
|
2005-01-16 13:16:23 +01:00
|
|
|
/* nothing */ { Lex->xa_opt=XA_NONE; }
|
|
|
|
| SUSPEND_SYM { Lex->xa_opt=XA_SUSPEND; }
|
2005-08-19 16:00:16 +02:00
|
|
|
opt_migrate
|
|
|
|
;
|
|
|
|
|
|
|
|
opt_migrate:
|
|
|
|
/* nothing */ { }
|
2005-01-16 13:16:23 +01:00
|
|
|
| FOR_SYM MIGRATE_SYM { Lex->xa_opt=XA_FOR_MIGRATE; }
|
|
|
|
;
|
|
|
|
|
2005-11-06 13:13:06 +01:00
|
|
|
install:
|
2005-12-21 19:18:40 +01:00
|
|
|
INSTALL_SYM PLUGIN_SYM ident SONAME_SYM TEXT_STRING_sys
|
2005-11-06 13:13:06 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command= SQLCOM_INSTALL_PLUGIN;
|
|
|
|
lex->comment= $3;
|
|
|
|
lex->ident= $5;
|
|
|
|
};
|
2005-01-16 13:16:23 +01:00
|
|
|
|
2005-11-06 13:13:06 +01:00
|
|
|
uninstall:
|
2005-12-21 19:18:40 +01:00
|
|
|
UNINSTALL_SYM PLUGIN_SYM ident
|
2005-11-06 13:13:06 +01:00
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command= SQLCOM_UNINSTALL_PLUGIN;
|
|
|
|
lex->comment= $3;
|
|
|
|
};
|