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"
|
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
|
|
|
|
2007-03-01 08:41:13 +01:00
|
|
|
#undef WARN_DEPRECATED /* this macro is also defined in mysql_priv.h */
|
2005-04-04 00:50:05 +02:00
|
|
|
#define WARN_DEPRECATED(A,B) \
|
2003-12-10 05:31:42 +01:00
|
|
|
push_warning_printf(((THD *)yythd), MYSQL_ERROR::WARN_LEVEL_WARN, \
|
2005-04-04 00:50:05 +02:00
|
|
|
ER_WARN_DEPRECATED_SYNTAX, \
|
2005-01-16 13:16:23 +01:00
|
|
|
ER(ER_WARN_DEPRECATED_SYNTAX), (A), (B));
|
2003-12-10 05:31:42 +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
|
|
|
#define MYSQL_YYABORT \
|
|
|
|
do \
|
|
|
|
{ \
|
|
|
|
LEX::cleanup_lex_after_parse_error(YYTHD);\
|
|
|
|
YYABORT; \
|
|
|
|
} 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
|
|
|
}
|
|
|
|
|
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;
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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 I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
const char *yytext= lip->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,
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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#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;
|
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;
|
|
|
|
key_part_spec *key_part;
|
|
|
|
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;
|
2000-07-31 21:29:14 +02:00
|
|
|
enum db_type db_type;
|
|
|
|
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;
|
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
|
|
|
/*
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
Currently there are 245 shift/reduce conflicts.
|
|
|
|
We should not introduce new conflicts any more.
|
2007-03-02 13:05:16 +01:00
|
|
|
*/
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
%expect 245
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-02-14 21:50:09 +01:00
|
|
|
%token END_OF_INPUT
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2005-01-16 13:16:23 +01:00
|
|
|
%token ABORT_SYM
|
|
|
|
%token ACTION
|
|
|
|
%token ADD
|
|
|
|
%token ADDDATE_SYM
|
|
|
|
%token AFTER_SYM
|
|
|
|
%token AGAINST
|
|
|
|
%token AGGREGATE_SYM
|
|
|
|
%token ALGORITHM_SYM
|
|
|
|
%token ALL
|
|
|
|
%token ALTER
|
|
|
|
%token ANALYZE_SYM
|
|
|
|
%token AND_AND_SYM
|
|
|
|
%token AND_SYM
|
|
|
|
%token ANY_SYM
|
|
|
|
%token AS
|
|
|
|
%token ASC
|
|
|
|
%token ASCII_SYM
|
|
|
|
%token ASENSITIVE_SYM
|
|
|
|
%token ATAN
|
|
|
|
%token AUTO_INC
|
|
|
|
%token AVG_ROW_LENGTH
|
|
|
|
%token AVG_SYM
|
|
|
|
%token BACKUP_SYM
|
|
|
|
%token BEFORE_SYM
|
|
|
|
%token BEGIN_SYM
|
|
|
|
%token BENCHMARK_SYM
|
|
|
|
%token BERKELEY_DB_SYM
|
|
|
|
%token BIGINT
|
|
|
|
%token BINARY
|
|
|
|
%token BINLOG_SYM
|
2004-12-17 15:06:05 +01:00
|
|
|
%token BIN_NUM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token BIT_AND
|
|
|
|
%token BIT_OR
|
|
|
|
%token BIT_SYM
|
|
|
|
%token BIT_XOR
|
|
|
|
%token BLOB_SYM
|
|
|
|
%token BOOLEAN_SYM
|
|
|
|
%token BOOL_SYM
|
|
|
|
%token BOTH
|
|
|
|
%token BTREE_SYM
|
|
|
|
%token BY
|
|
|
|
%token BYTE_SYM
|
|
|
|
%token CACHE_SYM
|
|
|
|
%token CALL_SYM
|
|
|
|
%token CASCADE
|
2004-11-12 04:01:46 +01:00
|
|
|
%token CASCADED
|
2005-01-16 13:16:23 +01:00
|
|
|
%token CAST_SYM
|
2005-02-14 21:50:09 +01:00
|
|
|
%token CHAIN_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token CHANGE
|
|
|
|
%token CHANGED
|
|
|
|
%token CHARSET
|
|
|
|
%token CHAR_SYM
|
|
|
|
%token CHECKSUM_SYM
|
|
|
|
%token CHECK_SYM
|
|
|
|
%token CIPHER_SYM
|
|
|
|
%token CLIENT_SYM
|
|
|
|
%token CLOSE_SYM
|
|
|
|
%token COALESCE
|
2005-11-17 11:11:48 +01:00
|
|
|
%token CODE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token COLLATE_SYM
|
|
|
|
%token COLLATION_SYM
|
|
|
|
%token COLUMNS
|
|
|
|
%token COLUMN_SYM
|
|
|
|
%token COMMENT_SYM
|
|
|
|
%token COMMITTED_SYM
|
|
|
|
%token COMMIT_SYM
|
2005-02-14 21:50:09 +01:00
|
|
|
%token COMPACT_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token COMPRESSED_SYM
|
|
|
|
%token CONCAT
|
|
|
|
%token CONCAT_WS
|
|
|
|
%token CONCURRENT
|
2004-11-12 04:01:46 +01:00
|
|
|
%token CONDITION_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token CONNECTION_SYM
|
|
|
|
%token CONSISTENT_SYM
|
|
|
|
%token CONSTRAINT
|
2004-11-12 04:01:46 +01:00
|
|
|
%token CONTAINS_SYM
|
|
|
|
%token CONTINUE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token CONVERT_SYM
|
|
|
|
%token CONVERT_TZ_SYM
|
|
|
|
%token COUNT_SYM
|
|
|
|
%token CREATE
|
|
|
|
%token CROSS
|
|
|
|
%token CUBE_SYM
|
|
|
|
%token CURDATE
|
2004-04-05 14:55:26 +02:00
|
|
|
%token CURRENT_USER
|
2005-01-16 13:16:23 +01:00
|
|
|
%token CURSOR_SYM
|
|
|
|
%token CURTIME
|
|
|
|
%token DATABASE
|
|
|
|
%token DATABASES
|
|
|
|
%token DATA_SYM
|
|
|
|
%token DATETIME
|
|
|
|
%token DATE_ADD_INTERVAL
|
|
|
|
%token DATE_SUB_INTERVAL
|
|
|
|
%token DATE_SYM
|
|
|
|
%token DAY_HOUR_SYM
|
|
|
|
%token DAY_MICROSECOND_SYM
|
|
|
|
%token DAY_MINUTE_SYM
|
|
|
|
%token DAY_SECOND_SYM
|
|
|
|
%token DAY_SYM
|
|
|
|
%token DEALLOCATE_SYM
|
2005-02-14 21:50:09 +01:00
|
|
|
%token DECIMAL_NUM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token DECIMAL_SYM
|
2004-11-12 04:01:46 +01:00
|
|
|
%token DECLARE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token DECODE_SYM
|
|
|
|
%token DEFAULT
|
|
|
|
%token DEFINER_SYM
|
|
|
|
%token DELAYED_SYM
|
|
|
|
%token DELAY_KEY_WRITE_SYM
|
|
|
|
%token DELETE_SYM
|
|
|
|
%token DESC
|
|
|
|
%token DESCRIBE
|
|
|
|
%token DES_DECRYPT_SYM
|
|
|
|
%token DES_ENCRYPT_SYM
|
|
|
|
%token DES_KEY_FILE
|
|
|
|
%token DETERMINISTIC_SYM
|
|
|
|
%token DIRECTORY_SYM
|
|
|
|
%token DISABLE_SYM
|
|
|
|
%token DISCARD
|
|
|
|
%token DISTINCT
|
|
|
|
%token DIV_SYM
|
|
|
|
%token DOUBLE_SYM
|
|
|
|
%token DO_SYM
|
|
|
|
%token DROP
|
|
|
|
%token DUAL_SYM
|
|
|
|
%token DUMPFILE
|
2003-01-21 20:07:59 +01:00
|
|
|
%token DUPLICATE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token DYNAMIC_SYM
|
2004-11-12 04:01:46 +01:00
|
|
|
%token EACH_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token ELSEIF_SYM
|
|
|
|
%token ELT_FUNC
|
|
|
|
%token ENABLE_SYM
|
|
|
|
%token ENCLOSED
|
|
|
|
%token ENCODE_SYM
|
|
|
|
%token ENCRYPT
|
|
|
|
%token END
|
|
|
|
%token ENGINES_SYM
|
|
|
|
%token ENGINE_SYM
|
|
|
|
%token ENUM
|
|
|
|
%token EQ
|
|
|
|
%token EQUAL_SYM
|
|
|
|
%token ERRORS
|
|
|
|
%token ESCAPED
|
|
|
|
%token ESCAPE_SYM
|
|
|
|
%token EVENTS_SYM
|
|
|
|
%token EXECUTE_SYM
|
|
|
|
%token EXISTS
|
2004-11-12 04:01:46 +01:00
|
|
|
%token EXIT_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token EXPANSION_SYM
|
|
|
|
%token EXPORT_SET
|
|
|
|
%token EXTENDED_SYM
|
|
|
|
%token EXTRACT_SYM
|
|
|
|
%token FALSE_SYM
|
|
|
|
%token FAST_SYM
|
2004-11-12 04:01:46 +01:00
|
|
|
%token FETCH_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token FIELD_FUNC
|
|
|
|
%token FILE_SYM
|
|
|
|
%token FIRST_SYM
|
|
|
|
%token FIXED_SYM
|
|
|
|
%token FLOAT_NUM
|
|
|
|
%token FLOAT_SYM
|
|
|
|
%token FLUSH_SYM
|
|
|
|
%token FORCE_SYM
|
|
|
|
%token FOREIGN
|
|
|
|
%token FORMAT_SYM
|
|
|
|
%token FOR_SYM
|
2004-11-12 04:01:46 +01:00
|
|
|
%token FOUND_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token FRAC_SECOND_SYM
|
|
|
|
%token FROM
|
|
|
|
%token FROM_UNIXTIME
|
|
|
|
%token FULL
|
|
|
|
%token FULLTEXT_SYM
|
|
|
|
%token FUNCTION_SYM
|
|
|
|
%token FUNC_ARG0
|
|
|
|
%token FUNC_ARG1
|
|
|
|
%token FUNC_ARG2
|
|
|
|
%token FUNC_ARG3
|
|
|
|
%token GE
|
|
|
|
%token GEOMCOLLFROMTEXT
|
|
|
|
%token GEOMETRYCOLLECTION
|
|
|
|
%token GEOMETRY_SYM
|
|
|
|
%token GEOMFROMTEXT
|
|
|
|
%token GEOMFROMWKB
|
|
|
|
%token GET_FORMAT
|
|
|
|
%token GLOBAL_SYM
|
|
|
|
%token GRANT
|
|
|
|
%token GRANTS
|
|
|
|
%token GREATEST_SYM
|
|
|
|
%token GROUP
|
|
|
|
%token GROUP_CONCAT_SYM
|
|
|
|
%token GROUP_UNIQUE_USERS
|
|
|
|
%token GT_SYM
|
|
|
|
%token HANDLER_SYM
|
|
|
|
%token HASH_SYM
|
|
|
|
%token HAVING
|
|
|
|
%token HELP_SYM
|
|
|
|
%token HEX_NUM
|
|
|
|
%token HIGH_PRIORITY
|
|
|
|
%token HOSTS_SYM
|
|
|
|
%token HOUR_MICROSECOND_SYM
|
|
|
|
%token HOUR_MINUTE_SYM
|
|
|
|
%token HOUR_SECOND_SYM
|
|
|
|
%token HOUR_SYM
|
|
|
|
%token IDENT
|
|
|
|
%token IDENTIFIED_SYM
|
|
|
|
%token IDENT_QUOTED
|
|
|
|
%token IF
|
|
|
|
%token IGNORE_SYM
|
|
|
|
%token IMPORT
|
|
|
|
%token INDEXES
|
|
|
|
%token INDEX_SYM
|
|
|
|
%token INFILE
|
|
|
|
%token INNER_SYM
|
|
|
|
%token INNOBASE_SYM
|
2004-11-12 04:01:46 +01:00
|
|
|
%token INOUT_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token INSENSITIVE_SYM
|
|
|
|
%token INSERT
|
|
|
|
%token INSERT_METHOD
|
|
|
|
%token INTERVAL_SYM
|
|
|
|
%token INTO
|
|
|
|
%token INT_SYM
|
2004-11-12 04:01:46 +01:00
|
|
|
%token INVOKER_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token IN_SYM
|
|
|
|
%token IS
|
|
|
|
%token ISOLATION
|
|
|
|
%token ISSUER_SYM
|
|
|
|
%token ITERATE_SYM
|
|
|
|
%token JOIN_SYM
|
|
|
|
%token KEYS
|
|
|
|
%token KEY_SYM
|
|
|
|
%token KILL_SYM
|
|
|
|
%token LABEL_SYM
|
2004-11-12 04:01:46 +01:00
|
|
|
%token LANGUAGE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token LAST_INSERT_ID
|
|
|
|
%token LAST_SYM
|
|
|
|
%token LE
|
|
|
|
%token LEADING
|
|
|
|
%token LEAST_SYM
|
|
|
|
%token LEAVES
|
|
|
|
%token LEAVE_SYM
|
|
|
|
%token LEFT
|
|
|
|
%token LEVEL_SYM
|
|
|
|
%token LEX_HOSTNAME
|
|
|
|
%token LIKE
|
|
|
|
%token LIMIT
|
|
|
|
%token LINEFROMTEXT
|
|
|
|
%token LINES
|
|
|
|
%token LINESTRING
|
|
|
|
%token LOAD
|
|
|
|
%token LOCAL_SYM
|
|
|
|
%token LOCATE
|
2004-11-12 04:01:46 +01:00
|
|
|
%token LOCATOR_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token LOCKS_SYM
|
|
|
|
%token LOCK_SYM
|
|
|
|
%token LOGS_SYM
|
|
|
|
%token LOG_SYM
|
|
|
|
%token LONGBLOB
|
|
|
|
%token LONGTEXT
|
|
|
|
%token LONG_NUM
|
|
|
|
%token LONG_SYM
|
|
|
|
%token LOOP_SYM
|
|
|
|
%token LOW_PRIORITY
|
|
|
|
%token LT
|
|
|
|
%token MAKE_SET_SYM
|
|
|
|
%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_POS_WAIT
|
|
|
|
%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
|
|
|
|
%token MASTER_SYM
|
|
|
|
%token MASTER_USER_SYM
|
|
|
|
%token MATCH
|
|
|
|
%token MAX_CONNECTIONS_PER_HOUR
|
|
|
|
%token MAX_QUERIES_PER_HOUR
|
|
|
|
%token MAX_ROWS
|
|
|
|
%token MAX_SYM
|
|
|
|
%token MAX_UPDATES_PER_HOUR
|
2005-02-14 21:50:09 +01:00
|
|
|
%token MAX_USER_CONNECTIONS_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token MEDIUMBLOB
|
|
|
|
%token MEDIUMINT
|
|
|
|
%token MEDIUMTEXT
|
|
|
|
%token MEDIUM_SYM
|
|
|
|
%token MERGE_SYM
|
|
|
|
%token MICROSECOND_SYM
|
|
|
|
%token MIGRATE_SYM
|
|
|
|
%token MINUTE_MICROSECOND_SYM
|
|
|
|
%token MINUTE_SECOND_SYM
|
|
|
|
%token MINUTE_SYM
|
|
|
|
%token MIN_ROWS
|
|
|
|
%token MIN_SYM
|
|
|
|
%token MLINEFROMTEXT
|
|
|
|
%token MODE_SYM
|
|
|
|
%token MODIFIES_SYM
|
|
|
|
%token MODIFY_SYM
|
|
|
|
%token MOD_SYM
|
|
|
|
%token MONTH_SYM
|
|
|
|
%token MPOINTFROMTEXT
|
|
|
|
%token MPOLYFROMTEXT
|
|
|
|
%token MULTILINESTRING
|
|
|
|
%token MULTIPOINT
|
|
|
|
%token MULTIPOLYGON
|
2004-12-24 13:31:21 +01:00
|
|
|
%token MUTEX_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token NAMES_SYM
|
|
|
|
%token NAME_SYM
|
|
|
|
%token NATIONAL_SYM
|
|
|
|
%token NATURAL
|
|
|
|
%token NCHAR_STRING
|
|
|
|
%token NCHAR_SYM
|
2004-04-15 09:14:14 +02:00
|
|
|
%token NDBCLUSTER_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token NE
|
|
|
|
%token NEW_SYM
|
|
|
|
%token NEXT_SYM
|
|
|
|
%token NONE_SYM
|
|
|
|
%token NOT2_SYM
|
|
|
|
%token NOT_SYM
|
|
|
|
%token NOW_SYM
|
|
|
|
%token NO_SYM
|
|
|
|
%token NO_WRITE_TO_BINLOG
|
|
|
|
%token NULL_SYM
|
|
|
|
%token NUM
|
|
|
|
%token NUMERIC_SYM
|
2003-09-15 07:26:48 +02:00
|
|
|
%token NVARCHAR_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token OFFSET_SYM
|
2006-05-13 20:56:05 +02:00
|
|
|
%token OJ_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token OLD_PASSWORD
|
|
|
|
%token ON
|
2004-06-03 23:17:18 +02:00
|
|
|
%token ONE_SHOT_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token ONE_SYM
|
|
|
|
%token OPEN_SYM
|
|
|
|
%token OPTIMIZE
|
|
|
|
%token OPTION
|
|
|
|
%token OPTIONALLY
|
|
|
|
%token OR2_SYM
|
|
|
|
%token ORDER_SYM
|
|
|
|
%token OR_OR_SYM
|
|
|
|
%token OR_SYM
|
|
|
|
%token OUTER
|
|
|
|
%token OUTFILE
|
2004-11-12 04:01:46 +01:00
|
|
|
%token OUT_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token PACK_KEYS_SYM
|
|
|
|
%token PARTIAL
|
|
|
|
%token PASSWORD
|
2005-07-14 22:01:49 +02:00
|
|
|
%token PARAM_MARKER
|
2005-01-16 13:16:23 +01:00
|
|
|
%token PHASE_SYM
|
|
|
|
%token POINTFROMTEXT
|
|
|
|
%token POINT_SYM
|
|
|
|
%token POLYFROMTEXT
|
|
|
|
%token POLYGON
|
|
|
|
%token POSITION_SYM
|
|
|
|
%token PRECISION
|
|
|
|
%token PREPARE_SYM
|
|
|
|
%token PREV_SYM
|
|
|
|
%token PRIMARY_SYM
|
|
|
|
%token PRIVILEGES
|
|
|
|
%token PROCEDURE
|
|
|
|
%token PROCESS
|
|
|
|
%token PROCESSLIST_SYM
|
|
|
|
%token PURGE
|
|
|
|
%token QUARTER_SYM
|
|
|
|
%token QUERY_SYM
|
|
|
|
%token QUICK
|
|
|
|
%token RAID_0_SYM
|
|
|
|
%token RAID_CHUNKS
|
|
|
|
%token RAID_CHUNKSIZE
|
|
|
|
%token RAID_STRIPED_SYM
|
|
|
|
%token RAID_TYPE
|
|
|
|
%token RAND
|
|
|
|
%token READS_SYM
|
|
|
|
%token READ_SYM
|
|
|
|
%token REAL
|
|
|
|
%token RECOVER_SYM
|
2005-02-14 21:50:09 +01:00
|
|
|
%token REDUNDANT_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token REFERENCES
|
|
|
|
%token REGEXP
|
|
|
|
%token RELAY_LOG_FILE_SYM
|
|
|
|
%token RELAY_LOG_POS_SYM
|
|
|
|
%token RELAY_THREAD
|
2005-02-14 21:50:09 +01:00
|
|
|
%token RELEASE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token RELOAD
|
|
|
|
%token RENAME
|
|
|
|
%token REPAIR
|
|
|
|
%token REPEATABLE_SYM
|
|
|
|
%token REPEAT_SYM
|
|
|
|
%token REPLACE
|
|
|
|
%token REPLICATION
|
|
|
|
%token REQUIRE_SYM
|
|
|
|
%token RESET_SYM
|
|
|
|
%token RESOURCES
|
|
|
|
%token RESTORE_SYM
|
|
|
|
%token RESTRICT
|
|
|
|
%token RESUME_SYM
|
|
|
|
%token RETURNS_SYM
|
|
|
|
%token RETURN_SYM
|
|
|
|
%token REVOKE
|
|
|
|
%token RIGHT
|
|
|
|
%token ROLLBACK_SYM
|
|
|
|
%token ROLLUP_SYM
|
|
|
|
%token ROUND
|
2005-02-14 21:50:09 +01:00
|
|
|
%token ROUTINE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token ROWS_SYM
|
|
|
|
%token ROW_COUNT_SYM
|
|
|
|
%token ROW_FORMAT_SYM
|
|
|
|
%token ROW_SYM
|
|
|
|
%token RTREE_SYM
|
|
|
|
%token SAVEPOINT_SYM
|
|
|
|
%token SECOND_MICROSECOND_SYM
|
|
|
|
%token SECOND_SYM
|
2004-11-12 04:01:46 +01:00
|
|
|
%token SECURITY_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token SELECT_SYM
|
|
|
|
%token SENSITIVE_SYM
|
2003-03-18 00:07:40 +01:00
|
|
|
%token SEPARATOR_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token SERIALIZABLE_SYM
|
|
|
|
%token SERIAL_SYM
|
|
|
|
%token SESSION_SYM
|
|
|
|
%token SET
|
|
|
|
%token SET_VAR
|
|
|
|
%token SHARE_SYM
|
|
|
|
%token SHIFT_LEFT
|
|
|
|
%token SHIFT_RIGHT
|
|
|
|
%token SHOW
|
|
|
|
%token SHUTDOWN
|
|
|
|
%token SIGNED_SYM
|
|
|
|
%token SIMPLE_SYM
|
|
|
|
%token SLAVE
|
|
|
|
%token SMALLINT
|
|
|
|
%token SNAPSHOT_SYM
|
|
|
|
%token SOUNDS_SYM
|
|
|
|
%token SPATIAL_SYM
|
2004-11-12 04:01:46 +01:00
|
|
|
%token SPECIFIC_SYM
|
|
|
|
%token SQLEXCEPTION_SYM
|
|
|
|
%token SQLSTATE_SYM
|
|
|
|
%token SQLWARNING_SYM
|
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
|
|
|
|
%token SQL_SYM
|
|
|
|
%token SQL_THREAD
|
2001-09-30 04:46:20 +02:00
|
|
|
%token SSL_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token STARTING
|
|
|
|
%token START_SYM
|
|
|
|
%token STATUS_SYM
|
|
|
|
%token STD_SYM
|
2005-02-25 19:19:04 +01:00
|
|
|
%token STDDEV_SAMP_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token STOP_SYM
|
|
|
|
%token STORAGE_SYM
|
|
|
|
%token STRAIGHT_JOIN
|
|
|
|
%token STRING_SYM
|
|
|
|
%token SUBDATE_SYM
|
|
|
|
%token SUBJECT_SYM
|
|
|
|
%token SUBSTRING
|
|
|
|
%token SUBSTRING_INDEX
|
|
|
|
%token SUM_SYM
|
|
|
|
%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
|
|
|
|
%token TABLE_SYM
|
|
|
|
%token TEMPORARY
|
|
|
|
%token TEMPTABLE_SYM
|
|
|
|
%token TERMINATED
|
|
|
|
%token TEXT_STRING
|
|
|
|
%token TEXT_SYM
|
|
|
|
%token TIMESTAMP
|
|
|
|
%token TIMESTAMP_ADD
|
|
|
|
%token TIMESTAMP_DIFF
|
|
|
|
%token TIME_SYM
|
|
|
|
%token TINYBLOB
|
|
|
|
%token TINYINT
|
|
|
|
%token TINYTEXT
|
|
|
|
%token TO_SYM
|
|
|
|
%token TRAILING
|
|
|
|
%token TRANSACTION_SYM
|
2004-11-12 04:01:46 +01:00
|
|
|
%token TRIGGER_SYM
|
2005-07-19 18:06:49 +02:00
|
|
|
%token TRIGGERS_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token TRIM
|
|
|
|
%token TRUE_SYM
|
|
|
|
%token TRUNCATE_SYM
|
2002-06-12 23:13:12 +02:00
|
|
|
%token TYPES_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token TYPE_SYM
|
|
|
|
%token UDF_RETURNS_SYM
|
|
|
|
%token UDF_SONAME_SYM
|
|
|
|
%token ULONGLONG_NUM
|
|
|
|
%token UNCOMMITTED_SYM
|
|
|
|
%token UNDEFINED_SYM
|
|
|
|
%token UNDERSCORE_CHARSET
|
2004-11-12 04:01:46 +01:00
|
|
|
%token UNDO_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token UNICODE_SYM
|
|
|
|
%token UNION_SYM
|
|
|
|
%token UNIQUE_SYM
|
|
|
|
%token UNIQUE_USERS
|
|
|
|
%token UNIX_TIMESTAMP
|
|
|
|
%token UNKNOWN_SYM
|
|
|
|
%token UNLOCK_SYM
|
|
|
|
%token UNSIGNED
|
|
|
|
%token UNTIL_SYM
|
|
|
|
%token UPDATE_SYM
|
2006-02-17 07:52:32 +01:00
|
|
|
%token UPGRADE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token USAGE
|
|
|
|
%token USER
|
|
|
|
%token USE_FRM
|
|
|
|
%token USE_SYM
|
|
|
|
%token USING
|
|
|
|
%token UTC_DATE_SYM
|
|
|
|
%token UTC_TIMESTAMP_SYM
|
|
|
|
%token UTC_TIME_SYM
|
2005-02-25 19:19:04 +01:00
|
|
|
%token VAR_SAMP_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token VALUES
|
|
|
|
%token VALUE_SYM
|
|
|
|
%token VARBINARY
|
|
|
|
%token VARCHAR
|
|
|
|
%token VARIABLES
|
|
|
|
%token VARIANCE_SYM
|
|
|
|
%token VARYING
|
|
|
|
%token VIEW_SYM
|
|
|
|
%token WARNINGS
|
|
|
|
%token WEEK_SYM
|
|
|
|
%token WHEN_SYM
|
|
|
|
%token WHERE
|
2004-11-12 04:01:46 +01:00
|
|
|
%token WHILE_SYM
|
2005-01-16 13:16:23 +01:00
|
|
|
%token WITH
|
|
|
|
%token WORK_SYM
|
|
|
|
%token WRITE_SYM
|
|
|
|
%token X509_SYM
|
|
|
|
%token XA_SYM
|
|
|
|
%token XOR
|
|
|
|
%token YEARWEEK
|
|
|
|
%token YEAR_MONTH_SYM
|
|
|
|
%token YEAR_SYM
|
|
|
|
%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
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
%left OR_OR_SYM OR_SYM OR2_SYM
|
|
|
|
%left XOR
|
2004-11-17 16:49:10 +01:00
|
|
|
%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
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
%left INTERVAL_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
|
2003-04-08 11:38:17 +02:00
|
|
|
UNDERSCORE_CHARSET IDENT_sys TEXT_STRING_sys TEXT_STRING_literal
|
2003-11-18 12:47:27 +01:00
|
|
|
NCHAR_STRING opt_component key_cache_name
|
2006-02-14 05:24:01 +01:00
|
|
|
sp_opt_label BIN_NUM label_ident TEXT_STRING_filesystem
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
%type <lex_str_ptr>
|
|
|
|
opt_table_alias
|
|
|
|
|
|
|
|
%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
|
2004-12-06 17:01:51 +01:00
|
|
|
opt_constraint constraint ident_or_empty
|
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
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
%type <ulong_num>
|
2005-04-04 00:50:05 +02:00
|
|
|
ulong_num raid_types merge_insert_types
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2001-09-14 01:54:33 +02:00
|
|
|
%type <ulonglong_number>
|
|
|
|
ulonglong_num
|
2000-07-31 21:29:14 +02:00
|
|
|
|
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
|
2007-08-28 19:16:03 +02:00
|
|
|
variable variable_aux
|
|
|
|
bool_pri
|
|
|
|
predicate bit_expr
|
2004-11-17 16:49:10 +01:00
|
|
|
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
|
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>
|
|
|
|
key_alg opt_btree_or_rtree
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
%type <string_list>
|
2007-03-26 15:52:52 +02:00
|
|
|
key_usage_list 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
|
|
|
|
|
2003-12-17 23:52:03 +01:00
|
|
|
%type <db_type> 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
|
|
|
|
|
2005-07-06 16:37:57 +02:00
|
|
|
%type <symbol> FUNC_ARG0 FUNC_ARG1 FUNC_ARG2 FUNC_ARG3 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
|
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
|
2007-09-03 11:55:35 +02:00
|
|
|
opt_outer table_list table_name table_alias_ref_list table_alias_ref
|
|
|
|
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
|
2000-07-31 21:29:14 +02:00
|
|
|
equal optional_braces opt_key_definition key_usage_list2
|
|
|
|
opt_mi_check_type opt_to mi_check_types normal_join
|
2000-10-14 02:16:35 +02:00
|
|
|
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
|
2005-11-10 20:25:03 +01:00
|
|
|
definer view_replace_or_algorithm view_replace view_algorithm_opt
|
2006-03-02 13:18:49 +01:00
|
|
|
view_algorithm view_or_trigger_or_sp view_or_trigger_or_sp_tail
|
|
|
|
view_suid view_tail view_list_opt view_list view_select
|
|
|
|
view_check_option trigger_tail sp_tail
|
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
|
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
|
|
|
|
%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
|
|
|
|
|
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
|
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
|
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
|
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
|
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
|
|
|
{
|
|
|
|
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
|
|
|
{
|
|
|
|
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
|
|
|
|
{
|
|
|
|
THD *thd=YYTHD;
|
|
|
|
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
|
|
|
|
{
|
|
|
|
THD *thd=YYTHD;
|
|
|
|
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
|
|
|
|
{
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_CREATE_TABLE;
|
|
|
|
if (!lex->select_lex.add_table_to_list(thd, $5, NULL,
|
|
|
|
TL_OPTION_UPDATING,
|
2007-05-11 18:33:13 +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;
|
A fix and test cases for
Bug#4968 "Stored procedure crash if cursor opened on altered table"
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Test cases for bugs 4968, 19733, 6895 will be added 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 were not
re-execution friendly: during their operation they used to 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 (note that code in 5.1 already creates and
uses a copy of this structure in mysql_create_table()/alter_table(),
but this approach didn't work well for CREATE TABLE SELECT statement).
2006-12-08 00:20:09 +01: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;
|
|
|
|
lex->create_info.db_type= (enum db_type) lex->thd->variables.table_type;
|
|
|
|
lex->create_info.default_table_charset= NULL;
|
|
|
|
}
|
|
|
|
create2
|
|
|
|
{ Lex->current_select= &Lex->select_lex; }
|
|
|
|
| CREATE opt_unique_or_fulltext INDEX_SYM ident key_alg ON table_ident
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_CREATE_INDEX;
|
|
|
|
if (!lex->current_select->add_table_to_list(lex->thd, $7, 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;
|
A fix and test cases for
Bug#4968 "Stored procedure crash if cursor opened on altered table"
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Test cases for bugs 4968, 19733, 6895 will be added 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 were not
re-execution friendly: during their operation they used to 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 (note that code in 5.1 already creates and
uses a copy of this structure in mysql_create_table()/alter_table(),
but this approach didn't work well for CREATE TABLE SELECT statement).
2006-12-08 00:20:09 +01: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;
|
|
|
|
}
|
|
|
|
'(' key_list ')'
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
A fix and test cases for
Bug#4968 "Stored procedure crash if cursor opened on altered table"
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Test cases for bugs 4968, 19733, 6895 will be added 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 were not
re-execution friendly: during their operation they used to 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 (note that code in 5.1 already creates and
uses a copy of this structure in mysql_create_table()/alter_table(),
but this approach didn't work well for CREATE TABLE SELECT statement).
2006-12-08 00:20:09 +01:00
|
|
|
Key *key= new Key($2, $4.str, $5, 0, lex->col_list);
|
2004-11-12 04:01:46 +01:00
|
|
|
|
A fix and test cases for
Bug#4968 "Stored procedure crash if cursor opened on altered table"
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Test cases for bugs 4968, 19733, 6895 will be added 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 were not
re-execution friendly: during their operation they used to 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 (note that code in 5.1 already creates and
uses a copy of this structure in mysql_create_table()/alter_table(),
but this approach didn't work well for CREATE TABLE SELECT statement).
2006-12-08 00:20:09 +01:00
|
|
|
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;
|
|
|
|
lex->name=$4.str;
|
|
|
|
lex->create_info.options=$3;
|
|
|
|
}
|
2005-11-10 20:25:03 +01:00
|
|
|
| CREATE
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2005-11-10 20:25:03 +01:00
|
|
|
Lex->create_view_mode= VIEW_CREATE_NEW;
|
|
|
|
Lex->create_view_algorithm= VIEW_ALGORITHM_UNDEFINED;
|
|
|
|
Lex->create_view_suid= TRUE;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2006-03-02 13:18:49 +01:00
|
|
|
view_or_trigger_or_sp
|
2004-11-12 04:01:46 +01:00
|
|
|
{}
|
2004-11-25 21:55:49 +01:00
|
|
|
| CREATE USER clear_privileges grant_list
|
|
|
|
{
|
|
|
|
Lex->sql_command = SQLCOM_CREATE_USER;
|
|
|
|
}
|
2004-11-12 04:01:46 +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-01-11 15:11:05 +01:00
|
|
|
if (!$1.str || check_db_name($1.str))
|
|
|
|
{
|
|
|
|
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
|
|
|
}
|
2006-01-19 16:13:04 +01:00
|
|
|
if (check_routine_name($3))
|
2006-01-11 15:11:05 +01:00
|
|
|
{
|
|
|
|
my_error(ER_SP_WRONG_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;
|
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-05 09:34:04 +02:00
|
|
|
LEX *lex= 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;
|
2006-01-19 16:13:04 +01:00
|
|
|
if (check_routine_name($1))
|
2006-01-11 15:11:05 +01:00
|
|
|
{
|
|
|
|
my_error(ER_SP_WRONG_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-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 ($$)
|
|
|
|
$$->init_qname(YYTHD);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
create_function_tail:
|
|
|
|
RETURNS_SYM udf_type UDF_SONAME_SYM TEXT_STRING_sys
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
2006-07-31 21:01:43 +02:00
|
|
|
if (lex->definer != NULL)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
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
|
|
|
}
|
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;
|
|
|
|
}
|
|
|
|
| '('
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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;
|
|
|
|
|
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();
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
sp->reset_thd_mem_root(thd);
|
2004-11-12 04:01:46 +01:00
|
|
|
sp->init(lex);
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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;
|
|
|
|
/*
|
|
|
|
* We have to turn of CLIENT_MULTI_QUERIES while parsing a
|
|
|
|
* stored procedure, otherwise yylex will chop it into pieces
|
|
|
|
* at each ';'.
|
|
|
|
*/
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
sp->m_old_cmq= thd->client_capabilities & CLIENT_MULTI_QUERIES;
|
|
|
|
thd->client_capabilities &= ~CLIENT_MULTI_QUERIES;
|
|
|
|
lex->sphead->m_param_begin= lip->tok_start+1;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
sp_fdparam_list ')'
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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 I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
lex->sphead->m_param_end= lip->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;
|
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
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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;
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
lex->sphead->m_body_begin= lip->tok_start;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
sp_proc_stmt
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
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;
|
2006-07-27 15:57:43 +02:00
|
|
|
sp->init_strings(YYTHD, lex);
|
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
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
/* Restore flag if it was cleared above */
|
|
|
|
if (sp->m_old_cmq)
|
|
|
|
YYTHD->client_capabilities |= CLIENT_MULTI_QUERIES;
|
|
|
|
sp->restore_thd_mem_root(YYTHD);
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
|
|
|
/* 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. */
|
|
|
|
}
|
|
|
|
statement
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
|
|
|
|
if (lex->sql_command != SQLCOM_SELECT)
|
|
|
|
{
|
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:
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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 I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
lex->sphead->reset_lex(thd);
|
|
|
|
lex->sphead->m_tmp_query= lip->tok_start;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
statement
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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 I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
i->m_query.length= lip->ptr - sp->m_tmp_query;
|
2005-03-04 15:46:45 +01:00
|
|
|
else
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
i->m_query.length= lip->tok_end - sp->m_tmp_query;
|
|
|
|
i->m_query.str= strmake_root(thd->mem_root,
|
|
|
|
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
|
|
|
}
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
sp->restore_lex(thd);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2005-03-04 14:35:28 +01:00
|
|
|
| RETURN_SYM
|
|
|
|
{ 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-11-04 15:37:39 +01:00
|
|
|
| IF
|
|
|
|
{ Lex->sphead->new_cont_backpatch(NULL); }
|
|
|
|
sp_if END IF
|
|
|
|
{ Lex->sphead->do_cont_backpatch(); }
|
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
|
2004-11-12 04:01:46 +01:00
|
|
|
| sp_labeled_control
|
|
|
|
{}
|
|
|
|
| { /* Unlabeled controls get a secret label. */
|
|
|
|
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-07-06 16:37:57 +02:00
|
|
|
| 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-07-06 16:37:57 +02:00
|
|
|
| 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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
| OPEN_SYM ident
|
|
|
|
{
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
| FETCH_SYM sp_opt_fetch_noise ident INTO
|
|
|
|
{
|
|
|
|
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
|
|
|
|
{ }
|
|
|
|
| CLOSE_SYM ident
|
|
|
|
{
|
|
|
|
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
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
create2:
|
2004-09-13 11:19:38 +02:00
|
|
|
'(' create2a {}
|
|
|
|
| opt_create_table_options create3 {}
|
|
|
|
| LIKE table_ident
|
|
|
|
{
|
2007-05-23 13:22:13 +02:00
|
|
|
Lex->create_info.options|= HA_LEX_CREATE_TABLE_LIKE;
|
|
|
|
if (!Lex->select_lex.add_table_to_list(YYTHD, $2, NULL, 0, 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-09-13 11:19:38 +02:00
|
|
|
}
|
|
|
|
| '(' LIKE table_ident ')'
|
|
|
|
{
|
2007-05-23 13:22:13 +02:00
|
|
|
Lex->create_info.options|= HA_LEX_CREATE_TABLE_LIKE;
|
|
|
|
if (!Lex->select_lex.add_table_to_list(YYTHD, $3, NULL, 0, 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-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:
|
|
|
|
field_list ')' opt_create_table_options create3 {}
|
2003-08-18 23:08:08 +02:00
|
|
|
| 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
|
|
|
;
|
|
|
|
|
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; }
|
|
|
|
| TYPE_SYM opt_equal storage_engines { Lex->create_info.db_type= $3; WARN_DEPRECATED("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; }
|
2005-10-25 17:15:37 +02:00
|
|
|
| RAID_TYPE opt_equal raid_types
|
|
|
|
{
|
|
|
|
my_error(ER_WARN_DEPRECATED_SYNTAX, MYF(0), "RAID_TYPE", "PARTITION");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_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 17:15:37 +02:00
|
|
|
}
|
|
|
|
| RAID_CHUNKS opt_equal ulong_num
|
|
|
|
{
|
|
|
|
my_error(ER_WARN_DEPRECATED_SYNTAX, MYF(0), "RAID_CHUNKS", "PARTITION");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_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 17:15:37 +02:00
|
|
|
}
|
|
|
|
| RAID_CHUNKSIZE opt_equal ulong_num
|
|
|
|
{
|
|
|
|
my_error(ER_WARN_DEPRECATED_SYNTAX, MYF(0), "RAID_CHUNKSIZE", "PARTITION");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_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 17:15:37 +02:00
|
|
|
}
|
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=
|
|
|
|
(byte*) (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=
|
|
|
|
(byte**) &(table_list->next_local);
|
|
|
|
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; }
|
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; }
|
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
|
|
|
|
{
|
|
|
|
$$ = ha_resolve_by_name($1.str,$1.length);
|
|
|
|
if ($$ == DB_TYPE_UNKNOWN) {
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_UNKNOWN_STORAGE_ENGINE, 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-12-02 21:23:13 +01: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
|
|
|
|
|
|
|
raid_types:
|
|
|
|
RAID_STRIPED_SYM { $$= RAID_TYPE_0; }
|
|
|
|
| RAID_0_SYM { $$= RAID_TYPE_0; }
|
2005-04-04 00:50:05 +02:00
|
|
|
| ulong_num { $$=$1;};
|
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:
|
2003-02-26 00:03:47 +01:00
|
|
|
key_type opt_ident key_alg '(' key_list ')'
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2001-06-15 04:03:15 +02:00
|
|
|
LEX *lex=Lex;
|
A fix and test cases for
Bug#4968 "Stored procedure crash if cursor opened on altered table"
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Test cases for bugs 4968, 19733, 6895 will be added 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 were not
re-execution friendly: during their operation they used to 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 (note that code in 5.1 already creates and
uses a copy of this structure in mysql_create_table()/alter_table(),
but this approach didn't work well for CREATE TABLE SELECT statement).
2006-12-08 00:20:09 +01:00
|
|
|
Key *key= new Key($1, $2, $3, 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
|
|
|
}
|
2003-12-02 16:06:24 +01:00
|
|
|
| opt_constraint constraint_key_type opt_ident key_alg '(' key_list ')'
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
const char *key_name= $3 ? $3:$1;
|
A fix and test cases for
Bug#4968 "Stored procedure crash if cursor opened on altered table"
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Test cases for bugs 4968, 19733, 6895 will be added 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 were not
re-execution friendly: during their operation they used to 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 (note that code in 5.1 already creates and
uses a copy of this structure in mysql_create_table()/alter_table(),
but this approach didn't work well for CREATE TABLE SELECT statement).
2006-12-08 00:20:09 +01:00
|
|
|
Key *key= new Key($2, key_name, $4, 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;
|
A fix and test cases for
Bug#4968 "Stored procedure crash if cursor opened on altered table"
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Test cases for bugs 4968, 19733, 6895 will be added 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 were not
re-execution friendly: during their operation they used to 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 (note that code in 5.1 already creates and
uses a copy of this structure in mysql_create_table()/alter_table(),
but this approach didn't work well for CREATE TABLE SELECT statement).
2006-12-08 00:20:09 +01:00
|
|
|
const char *key_name= $4 ? $4 : $1;
|
|
|
|
Key *key= new foreign_key(key_name, lex->col_list,
|
|
|
|
$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,
|
|
|
|
HA_KEY_ALG_UNDEF, 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 */
|
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;
|
2002-12-06 20:11:27 +01:00
|
|
|
if (add_field_to_list(lex->thd, $1.str,
|
2000-07-31 21:29:14 +02:00
|
|
|
(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; }
|
|
|
|
| FLOAT_SYM float_options field_options { $$=FIELD_TYPE_FLOAT; }
|
2004-12-17 15:06:05 +01:00
|
|
|
| BIT_SYM { Lex->length= (char*) "1";
|
|
|
|
$$=FIELD_TYPE_BIT; }
|
|
|
|
| BIT_SYM '(' NUM ')' { Lex->length= $3.str;
|
|
|
|
$$=FIELD_TYPE_BIT; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| BOOL_SYM { Lex->length=(char*) "1";
|
|
|
|
$$=FIELD_TYPE_TINY; }
|
2002-12-01 13:59:06 +01:00
|
|
|
| BOOLEAN_SYM { Lex->length=(char*) "1";
|
|
|
|
$$=FIELD_TYPE_TINY; }
|
2002-09-12 16:36:22 +02:00
|
|
|
| char '(' NUM ')' opt_binary { Lex->length=$3.str;
|
2000-07-31 21:29:14 +02:00
|
|
|
$$=FIELD_TYPE_STRING; }
|
|
|
|
| char opt_binary { Lex->length=(char*) "1";
|
|
|
|
$$=FIELD_TYPE_STRING; }
|
2005-08-27 08:26:14 +02:00
|
|
|
| nchar '(' NUM ')' opt_bin_mod { Lex->length=$3.str;
|
2003-08-11 21:44:43 +02:00
|
|
|
$$=FIELD_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";
|
2003-08-11 21:44:43 +02:00
|
|
|
$$=FIELD_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;
|
2000-07-31 21:29:14 +02:00
|
|
|
$$=FIELD_TYPE_STRING; }
|
2004-11-16 09:05:13 +01:00
|
|
|
| BINARY { Lex->length= (char*) "1";
|
|
|
|
Lex->charset=&my_charset_bin;
|
|
|
|
$$=FIELD_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; }
|
2002-11-21 01:07:14 +01:00
|
|
|
| YEAR_SYM opt_len field_options { $$=FIELD_TYPE_YEAR; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| DATE_SYM { $$=FIELD_TYPE_DATE; }
|
|
|
|
| TIME_SYM { $$=FIELD_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)
|
2002-11-20 20:44:32 +01:00
|
|
|
$$=FIELD_TYPE_DATETIME;
|
|
|
|
else
|
2004-10-01 16:54:06 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
Unlike other types TIMESTAMP fields are NOT NULL by default.
|
|
|
|
*/
|
|
|
|
Lex->type|= NOT_NULL_FLAG;
|
2002-12-04 23:14:51 +01:00
|
|
|
$$=FIELD_TYPE_TIMESTAMP;
|
2004-10-01 16:54:06 +02:00
|
|
|
}
|
2002-11-20 20:44:32 +01:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| DATETIME { $$=FIELD_TYPE_DATETIME; }
|
2003-01-29 14:31:20 +01:00
|
|
|
| TINYBLOB { Lex->charset=&my_charset_bin;
|
2000-07-31 21:29:14 +02:00
|
|
|
$$=FIELD_TYPE_TINY_BLOB; }
|
2003-01-29 14:31:20 +01:00
|
|
|
| BLOB_SYM opt_len { Lex->charset=&my_charset_bin;
|
2000-07-31 21:29:14 +02:00
|
|
|
$$=FIELD_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;
|
|
|
|
$$=FIELD_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;
|
2000-07-31 21:29:14 +02:00
|
|
|
$$=FIELD_TYPE_MEDIUM_BLOB; }
|
2003-01-29 14:31:20 +01:00
|
|
|
| LONGBLOB { Lex->charset=&my_charset_bin;
|
2000-07-31 21:29:14 +02:00
|
|
|
$$=FIELD_TYPE_LONG_BLOB; }
|
2003-01-29 14:31:20 +01:00
|
|
|
| LONG_SYM VARBINARY { Lex->charset=&my_charset_bin;
|
2000-07-31 21:29:14 +02:00
|
|
|
$$=FIELD_TYPE_MEDIUM_BLOB; }
|
2002-06-07 14:23:33 +02:00
|
|
|
| LONG_SYM varchar opt_binary { $$=FIELD_TYPE_MEDIUM_BLOB; }
|
|
|
|
| TINYTEXT opt_binary { $$=FIELD_TYPE_TINY_BLOB; }
|
2002-11-21 01:07:14 +01:00
|
|
|
| TEXT_SYM opt_len opt_binary { $$=FIELD_TYPE_BLOB; }
|
2002-06-07 14:23:33 +02:00
|
|
|
| MEDIUMTEXT opt_binary { $$=FIELD_TYPE_MEDIUM_BLOB; }
|
|
|
|
| LONGTEXT opt_binary { $$=FIELD_TYPE_LONG_BLOB; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| DECIMAL_SYM float_options field_options
|
2005-02-08 23:50:45 +01:00
|
|
|
{ $$=FIELD_TYPE_NEWDECIMAL;}
|
2000-07-31 21:29:14 +02:00
|
|
|
| NUMERIC_SYM float_options field_options
|
2005-02-08 23:50:45 +01:00
|
|
|
{ $$=FIELD_TYPE_NEWDECIMAL;}
|
2002-11-21 01:07:14 +01:00
|
|
|
| FIXED_SYM float_options field_options
|
2005-02-08 23:50:45 +01:00
|
|
|
{ $$=FIELD_TYPE_NEWDECIMAL;}
|
2002-10-25 12:08:47 +02:00
|
|
|
| ENUM {Lex->interval_list.empty();} '(' string_list ')' opt_binary
|
2004-12-02 09:48:43 +01:00
|
|
|
{ $$=FIELD_TYPE_ENUM; }
|
2002-10-25 12:08:47 +02:00
|
|
|
| SET { Lex->interval_list.empty();} '(' string_list ')' opt_binary
|
2004-12-02 09:48:43 +01:00
|
|
|
{ $$=FIELD_TYPE_SET; }
|
2002-11-21 01:07:14 +01:00
|
|
|
| LONG_SYM opt_binary { $$=FIELD_TYPE_MEDIUM_BLOB; }
|
2002-11-25 11:11:16 +01:00
|
|
|
| SERIAL_SYM
|
|
|
|
{
|
|
|
|
$$=FIELD_TYPE_LONGLONG;
|
|
|
|
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:
|
|
|
|
INT_SYM { $$=FIELD_TYPE_LONG; }
|
|
|
|
| TINYINT { $$=FIELD_TYPE_TINY; }
|
|
|
|
| SMALLINT { $$=FIELD_TYPE_SHORT; }
|
|
|
|
| MEDIUMINT { $$=FIELD_TYPE_INT24; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| BIGINT { $$=FIELD_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 ?
|
2000-07-31 21:29:14 +02:00
|
|
|
FIELD_TYPE_FLOAT : FIELD_TYPE_DOUBLE; }
|
|
|
|
| DOUBLE_SYM { $$=FIELD_TYPE_DOUBLE; }
|
2002-04-16 01:09:30 +02:00
|
|
|
| DOUBLE_SYM PRECISION { $$=FIELD_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:
|
|
|
|
ref_list ',' ident { Lex->ref_list.push_back(new key_part_spec($3.str)); }
|
2002-06-03 11:59:31 +02:00
|
|
|
| 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; }
|
|
|
|
| MATCH FULL { Lex->fk_match_option= foreign_key::FK_MATCH_FULL; }
|
|
|
|
| MATCH PARTIAL { Lex->fk_match_option= foreign_key::FK_MATCH_PARTIAL; }
|
2002-06-03 11:59:31 +02:00
|
|
|
| MATCH SIMPLE_SYM { Lex->fk_match_option= foreign_key::FK_MATCH_SIMPLE; };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
delete_option:
|
2002-06-02 20:22:20 +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; }
|
2002-06-03 11:59:31 +02:00
|
|
|
| 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
|
|
|
|
|
|
|
key_alg:
|
2002-04-25 10:36:55 +02:00
|
|
|
/* empty */ { $$= HA_KEY_ALG_UNDEF; }
|
2003-01-10 02:56:34 +01:00
|
|
|
| USING opt_btree_or_rtree { $$= $2; }
|
2003-01-09 21:42:31 +01:00
|
|
|
| TYPE_SYM opt_btree_or_rtree { $$= $2; };
|
2002-02-22 12:24:42 +01:00
|
|
|
|
|
|
|
opt_btree_or_rtree:
|
|
|
|
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:
|
|
|
|
ident { $$=new key_part_spec($1.str); }
|
2004-10-26 10:16:35 +02:00
|
|
|
| ident '(' NUM ')'
|
|
|
|
{
|
|
|
|
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
|
|
|
}
|
|
|
|
$$=new key_part_spec($1.str,(uint) key_part_len);
|
|
|
|
};
|
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;
|
2004-12-31 11:04:35 +01:00
|
|
|
lex->sql_command= SQLCOM_ALTER_TABLE;
|
|
|
|
lex->name= 0;
|
|
|
|
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;
|
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;
|
|
|
|
lex->name=0;
|
2002-11-29 16:17:52 +01:00
|
|
|
bzero((char*) &lex->create_info,sizeof(lex->create_info));
|
2000-07-31 21:29:14 +02:00
|
|
|
lex->create_info.db_type= DB_TYPE_DEFAULT;
|
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;
|
2006-12-11 23:50:12 +01:00
|
|
|
lex->alter_info.reset();
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2002-11-28 18:57:56 +01:00
|
|
|
alter_list
|
|
|
|
{}
|
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;
|
2007-07-05 09:34:04 +02:00
|
|
|
if (lex->name == NULL && lex->copy_db_to(&lex->name, 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;
|
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;
|
|
|
|
}
|
2005-11-10 20:25:03 +01:00
|
|
|
| ALTER view_algorithm_opt definer view_suid
|
|
|
|
VIEW_SYM table_ident
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
2007-06-22 11:55:48 +02:00
|
|
|
if (lex->sphead)
|
|
|
|
{
|
|
|
|
my_error(ER_SP_BADSTATEMENT, MYF(0), "ALTER VIEW");
|
|
|
|
MYSQL_YYABORT;
|
|
|
|
}
|
2004-11-12 04:01:46 +01:00
|
|
|
lex->sql_command= SQLCOM_CREATE_VIEW;
|
|
|
|
lex->create_view_mode= VIEW_ALTER;
|
|
|
|
/* first table in list is target VIEW name */
|
2006-04-12 11:50:12 +02:00
|
|
|
lex->select_lex.add_table_to_list(thd, $6, NULL, TL_OPTION_UPDATING);
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2005-11-10 20:25:03 +01:00
|
|
|
view_list_opt AS view_select view_check_option
|
2004-11-12 04:01:46 +01:00
|
|
|
{}
|
|
|
|
;
|
2002-06-27 11:41:02 +02:00
|
|
|
|
2004-12-06 17:01:51 +01:00
|
|
|
ident_or_empty:
|
|
|
|
/* empty */ { $$= 0; }
|
|
|
|
| ident { $$= $1.str; };
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
alter_list:
|
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; }
|
2000-11-11 19:27:34 +01:00
|
|
|
| alter_list_item
|
2002-04-16 01:09:30 +02:00
|
|
|
| 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;
|
2002-12-06 20:11:27 +01:00
|
|
|
if (add_field_to_list(lex->thd,$3.str,
|
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
|
|
|
|
{
|
|
|
|
Lex->alter_info.flags|= ALTER_DROP_INDEX;
|
|
|
|
}
|
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;
|
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-05 09:34:04 +02:00
|
|
|
lex->copy_db_to(&lex->select_lex.db, NULL))
|
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) ||
|
|
|
|
$3->db.str && check_db_name($3->db.str))
|
|
|
|
{
|
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
|
|
|
}
|
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->name= $3->table.str;
|
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
|
|
|
|
|
|
|
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
|
|
|
|
{}
|
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
|
|
|
|
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
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
SELECT_LEX *sel= &lex->select_lex;
|
|
|
|
if (!sel->add_table_to_list(lex->thd, $1, NULL, 0,
|
|
|
|
TL_READ,
|
|
|
|
sel->get_use_index(),
|
2003-11-18 12:47:27 +01:00
|
|
|
(List<String> *)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-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
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
SELECT_LEX *sel= &lex->select_lex;
|
2003-08-11 21:44:43 +02:00
|
|
|
if (!sel->add_table_to_list(lex->thd, $1, NULL, $3,
|
|
|
|
TL_READ,
|
2003-06-12 13:29:02 +02:00
|
|
|
sel->get_use_index(),
|
|
|
|
(List<String> *)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-12 13:29:02 +02:00
|
|
|
}
|
|
|
|
;
|
|
|
|
|
2003-08-27 00:14:13 +02:00
|
|
|
cache_keys_spec:
|
2003-11-18 12:47:27 +01:00
|
|
|
{ Select->interval_list.empty(); }
|
2003-08-27 00:14:13 +02:00
|
|
|
cache_key_list_or_empty
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
SELECT_LEX *sel= &lex->select_lex;
|
|
|
|
sel->use_index= sel->interval_list;
|
|
|
|
}
|
|
|
|
;
|
2003-06-12 13:29:02 +02:00
|
|
|
|
2003-08-26 09:15:49 +02:00
|
|
|
cache_key_list_or_empty:
|
2003-11-18 12:47:27 +01:00
|
|
|
/* empty */ { Lex->select_lex.use_index_ptr= 0; }
|
2004-02-02 09:19:51 +01:00
|
|
|
| opt_key_or_index '(' key_usage_list2 ')'
|
2003-11-18 12:47:27 +01:00
|
|
|
{
|
|
|
|
SELECT_LEX *sel= &Lex->select_lex;
|
|
|
|
sel->use_index_ptr= &sel->use_index;
|
|
|
|
}
|
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:
|
2007-02-19 13:39:37 +01:00
|
|
|
FROM join_table_list where_clause group_clause having_clause
|
2004-05-19 14:51:41 +02:00
|
|
|
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
|
|
|
|
{
|
|
|
|
if (test_all_bits(Select->options, SELECT_ALL | SELECT_DISTINCT))
|
|
|
|
{
|
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-05-13 13:04:32 +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:
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
|
|
|
$$= (char*) lip->tok_start;
|
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
remember_end:
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
|
|
|
$$=(char*) lip->tok_end;
|
|
|
|
};
|
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 */
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
expr:
|
2007-08-28 19:16:03 +02:00
|
|
|
expr or expr %prec OR_SYM
|
2005-03-16 01:13:23 +01:00
|
|
|
{
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
/*
|
|
|
|
Design notes:
|
|
|
|
Do not use a manually maintained stack like thd->lex->xxx_list,
|
|
|
|
but use the internal bison stack ($$, $1 and $3) instead.
|
|
|
|
Using the bison stack is:
|
|
|
|
- more robust to changes in the grammar,
|
|
|
|
- guaranteed to be in sync with the parser state,
|
|
|
|
- better for performances (no memory allocation).
|
|
|
|
*/
|
|
|
|
Item_cond_or *item1;
|
|
|
|
Item_cond_or *item3;
|
|
|
|
if (is_cond_or($1))
|
2005-03-16 01:13:23 +01:00
|
|
|
{
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
item1= (Item_cond_or*) $1;
|
|
|
|
if (is_cond_or($3))
|
|
|
|
{
|
|
|
|
item3= (Item_cond_or*) $3;
|
|
|
|
/*
|
|
|
|
(X1 OR X2) OR (Y1 OR Y2) ==> OR (X1, X2, Y1, Y2)
|
|
|
|
*/
|
|
|
|
item3->add_at_head(item1->argument_list());
|
|
|
|
$$ = $3;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
(X1 OR X2) OR Y ==> OR (X1, X2, Y)
|
|
|
|
*/
|
|
|
|
item1->add($3);
|
|
|
|
$$ = $1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (is_cond_or($3))
|
|
|
|
{
|
|
|
|
item3= (Item_cond_or*) $3;
|
|
|
|
/*
|
|
|
|
X OR (Y1 OR Y2) ==> OR (X, Y1, Y2)
|
|
|
|
*/
|
|
|
|
item3->add_at_head($1);
|
|
|
|
$$ = $3;
|
2005-03-16 01:13:23 +01:00
|
|
|
}
|
|
|
|
else
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
{
|
|
|
|
/* X OR Y */
|
|
|
|
$$ = new (YYTHD->mem_root) Item_cond_or($1, $3);
|
|
|
|
}
|
2005-03-16 01:13:23 +01:00
|
|
|
}
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
| expr XOR expr %prec XOR
|
|
|
|
{
|
|
|
|
/* XOR is a proprietary extension */
|
|
|
|
$$ = new (YYTHD->mem_root) Item_cond_xor($1, $3);
|
|
|
|
}
|
|
|
|
| expr and expr %prec AND_SYM
|
2005-03-16 01:13:23 +01:00
|
|
|
{
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
/* See comments in rule expr: expr or expr */
|
|
|
|
Item_cond_and *item1;
|
|
|
|
Item_cond_and *item3;
|
|
|
|
if (is_cond_and($1))
|
2005-03-16 01:13:23 +01:00
|
|
|
{
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
item1= (Item_cond_and*) $1;
|
|
|
|
if (is_cond_and($3))
|
|
|
|
{
|
|
|
|
item3= (Item_cond_and*) $3;
|
|
|
|
/*
|
|
|
|
(X1 AND X2) AND (Y1 AND Y2) ==> AND (X1, X2, Y1, Y2)
|
|
|
|
*/
|
|
|
|
item3->add_at_head(item1->argument_list());
|
|
|
|
$$ = $3;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
(X1 AND X2) AND Y ==> AND (X1, X2, Y)
|
|
|
|
*/
|
|
|
|
item1->add($3);
|
|
|
|
$$ = $1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (is_cond_and($3))
|
|
|
|
{
|
|
|
|
item3= (Item_cond_and*) $3;
|
|
|
|
/*
|
|
|
|
X AND (Y1 AND Y2) ==> AND (X, Y1, Y2)
|
|
|
|
*/
|
|
|
|
item3->add_at_head($1);
|
|
|
|
$$ = $3;
|
2005-03-16 01:13:23 +01:00
|
|
|
}
|
|
|
|
else
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
{
|
|
|
|
/* X AND Y */
|
|
|
|
$$ = new (YYTHD->mem_root) Item_cond_and($1, $3);
|
|
|
|
}
|
2005-03-16 01:13:23 +01:00
|
|
|
}
|
2007-08-28 19:16:03 +02:00
|
|
|
| NOT_SYM expr %prec NOT_SYM
|
|
|
|
{ $$= negate_expression(YYTHD, $2); }
|
|
|
|
| bool_pri IS TRUE_SYM %prec IS
|
Bug#24532 (The return data type of IS TRUE is different from similar
operations)
Before this change, the boolean predicates:
- X IS TRUE,
- X IS NOT TRUE,
- X IS FALSE,
- X IS NOT FALSE
were implemented by expanding the Item tree in the parser, by using a
construct like:
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>)
Each <value> was a constant integer, either 0 or 1.
A bug in the implementation of the function IF(a, b, c), in
Item_func_if::fix_length_and_dec(), would cause the following :
When the arguments b and c are both unsigned, the result type of the
function was signed, instead of unsigned.
When the result of the if function is signed, space for the sign could be
counted twice (in the max() expression for a signed argument, and in the
total), causing the member max_length to be too high.
An effect of this is that the final type of IF(x, int(1), int(1)) would be
int(2) instead of int(1).
With this fix, the problems found in Item_func_if::fix_length_and_dec()
have been fixed.
While it's semantically correct to represent 'X IS TRUE' with
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>),
there are however more problems with this construct.
a)
Building the parse tree involves :
- creating 5 Item instances (3 ints, 1 ifnull, 1 if),
- creating each Item calls my_pthread_getspecific_ptr() once in the operator
new(size), and a second time in the Item::Item() constructor, resulting
in a total of 10 calls to get the current thread.
Evaluating the expression involves evaluating up to 4 nodes at runtime.
This representation could be greatly simplified and improved.
b)
Transforming the parse tree internally with if(ifnull(...)) is fine as long
as this transformation is internal to the server implementation.
With views however, the result of the parse tree is later exposed by the
::print() functions, and stored as part of the view definition.
Doing this has long term consequences:
1)
The original semantic 'X IS TRUE' is lost, and replaced by the
if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore
the original code.
2)
Should a future version of MySQL implement the SQL BOOLEAN data type for
example, views created today using 'X IS NULL' can be exported using
mysqldump, and imported again. Such views would be converted correctly and
automatically to use a BOOLEAN column in the future version.
With 'X IS TRUE' and the current implementations, views using these
"boolean" predicates would not be converted during the export/import, and
would use integer columns instead.
The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but
does not preserve the 'X IS TRUE' semantic.
With this fix, internal representation of 'X IS TRUE' booleans predicates
has changed, so that:
- dedicated Item classes are created for each predicate,
- only 1 Item is created to represent 1 predicate
- my_pthread_getspecific_ptr() is invoked 1 time instead of 10
- SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'.
Note that, because of the fix in Item_func_if, views created before this fix
will:
- correctly use a int(1) type instead of int(2) for boolean predicates,
- incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW,
since the original semantic (X IS TRUE) has been lost.
- except for the syntax used in SHOW CREATE VIEW, these views will operate
properly, no action is needed.
Views created after this fix will operate correctly, and will preserve the
original code semantic in SHOW CREATE VIEW.
2007-02-12 21:59:29 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_istrue($1); }
|
2007-08-28 19:16:03 +02:00
|
|
|
| bool_pri IS not TRUE_SYM %prec IS
|
Bug#24532 (The return data type of IS TRUE is different from similar
operations)
Before this change, the boolean predicates:
- X IS TRUE,
- X IS NOT TRUE,
- X IS FALSE,
- X IS NOT FALSE
were implemented by expanding the Item tree in the parser, by using a
construct like:
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>)
Each <value> was a constant integer, either 0 or 1.
A bug in the implementation of the function IF(a, b, c), in
Item_func_if::fix_length_and_dec(), would cause the following :
When the arguments b and c are both unsigned, the result type of the
function was signed, instead of unsigned.
When the result of the if function is signed, space for the sign could be
counted twice (in the max() expression for a signed argument, and in the
total), causing the member max_length to be too high.
An effect of this is that the final type of IF(x, int(1), int(1)) would be
int(2) instead of int(1).
With this fix, the problems found in Item_func_if::fix_length_and_dec()
have been fixed.
While it's semantically correct to represent 'X IS TRUE' with
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>),
there are however more problems with this construct.
a)
Building the parse tree involves :
- creating 5 Item instances (3 ints, 1 ifnull, 1 if),
- creating each Item calls my_pthread_getspecific_ptr() once in the operator
new(size), and a second time in the Item::Item() constructor, resulting
in a total of 10 calls to get the current thread.
Evaluating the expression involves evaluating up to 4 nodes at runtime.
This representation could be greatly simplified and improved.
b)
Transforming the parse tree internally with if(ifnull(...)) is fine as long
as this transformation is internal to the server implementation.
With views however, the result of the parse tree is later exposed by the
::print() functions, and stored as part of the view definition.
Doing this has long term consequences:
1)
The original semantic 'X IS TRUE' is lost, and replaced by the
if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore
the original code.
2)
Should a future version of MySQL implement the SQL BOOLEAN data type for
example, views created today using 'X IS NULL' can be exported using
mysqldump, and imported again. Such views would be converted correctly and
automatically to use a BOOLEAN column in the future version.
With 'X IS TRUE' and the current implementations, views using these
"boolean" predicates would not be converted during the export/import, and
would use integer columns instead.
The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but
does not preserve the 'X IS TRUE' semantic.
With this fix, internal representation of 'X IS TRUE' booleans predicates
has changed, so that:
- dedicated Item classes are created for each predicate,
- only 1 Item is created to represent 1 predicate
- my_pthread_getspecific_ptr() is invoked 1 time instead of 10
- SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'.
Note that, because of the fix in Item_func_if, views created before this fix
will:
- correctly use a int(1) type instead of int(2) for boolean predicates,
- incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW,
since the original semantic (X IS TRUE) has been lost.
- except for the syntax used in SHOW CREATE VIEW, these views will operate
properly, no action is needed.
Views created after this fix will operate correctly, and will preserve the
original code semantic in SHOW CREATE VIEW.
2007-02-12 21:59:29 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_isnottrue($1); }
|
2007-08-28 19:16:03 +02:00
|
|
|
| bool_pri IS FALSE_SYM %prec IS
|
Bug#24532 (The return data type of IS TRUE is different from similar
operations)
Before this change, the boolean predicates:
- X IS TRUE,
- X IS NOT TRUE,
- X IS FALSE,
- X IS NOT FALSE
were implemented by expanding the Item tree in the parser, by using a
construct like:
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>)
Each <value> was a constant integer, either 0 or 1.
A bug in the implementation of the function IF(a, b, c), in
Item_func_if::fix_length_and_dec(), would cause the following :
When the arguments b and c are both unsigned, the result type of the
function was signed, instead of unsigned.
When the result of the if function is signed, space for the sign could be
counted twice (in the max() expression for a signed argument, and in the
total), causing the member max_length to be too high.
An effect of this is that the final type of IF(x, int(1), int(1)) would be
int(2) instead of int(1).
With this fix, the problems found in Item_func_if::fix_length_and_dec()
have been fixed.
While it's semantically correct to represent 'X IS TRUE' with
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>),
there are however more problems with this construct.
a)
Building the parse tree involves :
- creating 5 Item instances (3 ints, 1 ifnull, 1 if),
- creating each Item calls my_pthread_getspecific_ptr() once in the operator
new(size), and a second time in the Item::Item() constructor, resulting
in a total of 10 calls to get the current thread.
Evaluating the expression involves evaluating up to 4 nodes at runtime.
This representation could be greatly simplified and improved.
b)
Transforming the parse tree internally with if(ifnull(...)) is fine as long
as this transformation is internal to the server implementation.
With views however, the result of the parse tree is later exposed by the
::print() functions, and stored as part of the view definition.
Doing this has long term consequences:
1)
The original semantic 'X IS TRUE' is lost, and replaced by the
if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore
the original code.
2)
Should a future version of MySQL implement the SQL BOOLEAN data type for
example, views created today using 'X IS NULL' can be exported using
mysqldump, and imported again. Such views would be converted correctly and
automatically to use a BOOLEAN column in the future version.
With 'X IS TRUE' and the current implementations, views using these
"boolean" predicates would not be converted during the export/import, and
would use integer columns instead.
The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but
does not preserve the 'X IS TRUE' semantic.
With this fix, internal representation of 'X IS TRUE' booleans predicates
has changed, so that:
- dedicated Item classes are created for each predicate,
- only 1 Item is created to represent 1 predicate
- my_pthread_getspecific_ptr() is invoked 1 time instead of 10
- SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'.
Note that, because of the fix in Item_func_if, views created before this fix
will:
- correctly use a int(1) type instead of int(2) for boolean predicates,
- incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW,
since the original semantic (X IS TRUE) has been lost.
- except for the syntax used in SHOW CREATE VIEW, these views will operate
properly, no action is needed.
Views created after this fix will operate correctly, and will preserve the
original code semantic in SHOW CREATE VIEW.
2007-02-12 21:59:29 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_isfalse($1); }
|
2007-08-28 19:16:03 +02:00
|
|
|
| bool_pri IS not FALSE_SYM %prec IS
|
Bug#24532 (The return data type of IS TRUE is different from similar
operations)
Before this change, the boolean predicates:
- X IS TRUE,
- X IS NOT TRUE,
- X IS FALSE,
- X IS NOT FALSE
were implemented by expanding the Item tree in the parser, by using a
construct like:
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>)
Each <value> was a constant integer, either 0 or 1.
A bug in the implementation of the function IF(a, b, c), in
Item_func_if::fix_length_and_dec(), would cause the following :
When the arguments b and c are both unsigned, the result type of the
function was signed, instead of unsigned.
When the result of the if function is signed, space for the sign could be
counted twice (in the max() expression for a signed argument, and in the
total), causing the member max_length to be too high.
An effect of this is that the final type of IF(x, int(1), int(1)) would be
int(2) instead of int(1).
With this fix, the problems found in Item_func_if::fix_length_and_dec()
have been fixed.
While it's semantically correct to represent 'X IS TRUE' with
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>),
there are however more problems with this construct.
a)
Building the parse tree involves :
- creating 5 Item instances (3 ints, 1 ifnull, 1 if),
- creating each Item calls my_pthread_getspecific_ptr() once in the operator
new(size), and a second time in the Item::Item() constructor, resulting
in a total of 10 calls to get the current thread.
Evaluating the expression involves evaluating up to 4 nodes at runtime.
This representation could be greatly simplified and improved.
b)
Transforming the parse tree internally with if(ifnull(...)) is fine as long
as this transformation is internal to the server implementation.
With views however, the result of the parse tree is later exposed by the
::print() functions, and stored as part of the view definition.
Doing this has long term consequences:
1)
The original semantic 'X IS TRUE' is lost, and replaced by the
if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore
the original code.
2)
Should a future version of MySQL implement the SQL BOOLEAN data type for
example, views created today using 'X IS NULL' can be exported using
mysqldump, and imported again. Such views would be converted correctly and
automatically to use a BOOLEAN column in the future version.
With 'X IS TRUE' and the current implementations, views using these
"boolean" predicates would not be converted during the export/import, and
would use integer columns instead.
The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but
does not preserve the 'X IS TRUE' semantic.
With this fix, internal representation of 'X IS TRUE' booleans predicates
has changed, so that:
- dedicated Item classes are created for each predicate,
- only 1 Item is created to represent 1 predicate
- my_pthread_getspecific_ptr() is invoked 1 time instead of 10
- SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'.
Note that, because of the fix in Item_func_if, views created before this fix
will:
- correctly use a int(1) type instead of int(2) for boolean predicates,
- incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW,
since the original semantic (X IS TRUE) has been lost.
- except for the syntax used in SHOW CREATE VIEW, these views will operate
properly, no action is needed.
Views created after this fix will operate correctly, and will preserve the
original code semantic in SHOW CREATE VIEW.
2007-02-12 21:59:29 +01:00
|
|
|
{ $$= new (YYTHD->mem_root) Item_func_isnotfalse($1); }
|
2007-08-28 19:16:03 +02:00
|
|
|
| bool_pri IS UNKNOWN_SYM %prec IS
|
|
|
|
{ $$= new Item_func_isnull($1); }
|
|
|
|
| bool_pri IS not UNKNOWN_SYM %prec IS
|
|
|
|
{ $$= new Item_func_isnotnull($1); }
|
Bug#24532 (The return data type of IS TRUE is different from similar
operations)
Before this change, the boolean predicates:
- X IS TRUE,
- X IS NOT TRUE,
- X IS FALSE,
- X IS NOT FALSE
were implemented by expanding the Item tree in the parser, by using a
construct like:
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>)
Each <value> was a constant integer, either 0 or 1.
A bug in the implementation of the function IF(a, b, c), in
Item_func_if::fix_length_and_dec(), would cause the following :
When the arguments b and c are both unsigned, the result type of the
function was signed, instead of unsigned.
When the result of the if function is signed, space for the sign could be
counted twice (in the max() expression for a signed argument, and in the
total), causing the member max_length to be too high.
An effect of this is that the final type of IF(x, int(1), int(1)) would be
int(2) instead of int(1).
With this fix, the problems found in Item_func_if::fix_length_and_dec()
have been fixed.
While it's semantically correct to represent 'X IS TRUE' with
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>),
there are however more problems with this construct.
a)
Building the parse tree involves :
- creating 5 Item instances (3 ints, 1 ifnull, 1 if),
- creating each Item calls my_pthread_getspecific_ptr() once in the operator
new(size), and a second time in the Item::Item() constructor, resulting
in a total of 10 calls to get the current thread.
Evaluating the expression involves evaluating up to 4 nodes at runtime.
This representation could be greatly simplified and improved.
b)
Transforming the parse tree internally with if(ifnull(...)) is fine as long
as this transformation is internal to the server implementation.
With views however, the result of the parse tree is later exposed by the
::print() functions, and stored as part of the view definition.
Doing this has long term consequences:
1)
The original semantic 'X IS TRUE' is lost, and replaced by the
if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore
the original code.
2)
Should a future version of MySQL implement the SQL BOOLEAN data type for
example, views created today using 'X IS NULL' can be exported using
mysqldump, and imported again. Such views would be converted correctly and
automatically to use a BOOLEAN column in the future version.
With 'X IS TRUE' and the current implementations, views using these
"boolean" predicates would not be converted during the export/import, and
would use integer columns instead.
The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but
does not preserve the 'X IS TRUE' semantic.
With this fix, internal representation of 'X IS TRUE' booleans predicates
has changed, so that:
- dedicated Item classes are created for each predicate,
- only 1 Item is created to represent 1 predicate
- my_pthread_getspecific_ptr() is invoked 1 time instead of 10
- SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'.
Note that, because of the fix in Item_func_if, views created before this fix
will:
- correctly use a int(1) type instead of int(2) for boolean predicates,
- incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW,
since the original semantic (X IS TRUE) has been lost.
- except for the syntax used in SHOW CREATE VIEW, these views will operate
properly, no action is needed.
Views created after this fix will operate correctly, and will preserve the
original code semantic in SHOW CREATE VIEW.
2007-02-12 21:59:29 +01:00
|
|
|
| bool_pri
|
|
|
|
;
|
2004-11-17 16:49:10 +01:00
|
|
|
|
|
|
|
bool_pri:
|
2007-08-28 19:16:03 +02:00
|
|
|
bool_pri IS NULL_SYM %prec IS
|
|
|
|
{ $$= new Item_func_isnull($1); }
|
|
|
|
| bool_pri IS not NULL_SYM %prec IS
|
|
|
|
{ $$= new Item_func_isnotnull($1); }
|
|
|
|
| bool_pri EQUAL_SYM predicate %prec EQUAL_SYM
|
|
|
|
{ $$= new Item_func_equal($1,$3); }
|
2005-02-04 00:08:43 +01:00
|
|
|
| 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:
|
2007-01-30 01:32:52 +01:00
|
|
|
bit_expr IN_SYM '(' subselect ')'
|
|
|
|
{
|
|
|
|
$$= new (YYTHD->mem_root) Item_in_subselect($1, $4);
|
|
|
|
}
|
|
|
|
| bit_expr not IN_SYM '(' subselect ')'
|
|
|
|
{
|
|
|
|
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
|
|
|
}
|
2007-01-30 01:32:52 +01:00
|
|
|
| bit_expr IN_SYM '(' expr ',' expr_list ')'
|
|
|
|
{
|
|
|
|
$6->push_front($4);
|
|
|
|
$6->push_front($1);
|
|
|
|
$$= 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
|
|
|
}
|
2007-01-30 01:32:52 +01:00
|
|
|
| bit_expr not IN_SYM '(' expr ',' expr_list ')'
|
2006-08-31 17:00:25 +02:00
|
|
|
{
|
2007-01-30 01:32:52 +01:00
|
|
|
$7->push_front($5);
|
|
|
|
$7->push_front($1);
|
|
|
|
Item_func_in *item = new (YYTHD->mem_root) Item_func_in(*$7);
|
|
|
|
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
|
2007-08-28 19:16:03 +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:
|
2007-08-28 19:16:03 +02:00
|
|
|
bit_expr '|' bit_expr %prec '|'
|
|
|
|
{ $$= new Item_func_bit_or($1,$3); }
|
|
|
|
| bit_expr '&' bit_expr %prec '&'
|
|
|
|
{ $$= new Item_func_bit_and($1,$3); }
|
|
|
|
| bit_expr SHIFT_LEFT bit_expr %prec SHIFT_LEFT
|
|
|
|
{ $$= new Item_func_shift_left($1,$3); }
|
|
|
|
| bit_expr SHIFT_RIGHT bit_expr %prec SHIFT_RIGHT
|
|
|
|
{ $$= new Item_func_shift_right($1,$3); }
|
|
|
|
| bit_expr '+' bit_expr %prec '+'
|
|
|
|
{ $$= new Item_func_plus($1,$3); }
|
|
|
|
| bit_expr '-' bit_expr %prec '-'
|
|
|
|
{ $$= new Item_func_minus($1,$3); }
|
|
|
|
| bit_expr '+' interval_expr interval %prec '+'
|
|
|
|
{ $$= new Item_date_add_interval($1,$3,$4,0); }
|
|
|
|
| bit_expr '-' interval_expr interval %prec '-'
|
|
|
|
{ $$= new Item_date_add_interval($1,$3,$4,1); }
|
|
|
|
| bit_expr '*' bit_expr %prec '*'
|
|
|
|
{ $$= new Item_func_mul($1,$3); }
|
|
|
|
| bit_expr '/' bit_expr %prec '/'
|
|
|
|
{ $$= new Item_func_div($1,$3); }
|
|
|
|
| bit_expr '%' bit_expr %prec '%'
|
|
|
|
{ $$= new Item_func_mod($1,$3); }
|
|
|
|
| bit_expr DIV_SYM bit_expr %prec DIV_SYM
|
|
|
|
{ $$= new Item_func_int_div($1,$3); }
|
|
|
|
| bit_expr MOD_SYM bit_expr %prec MOD_SYM
|
|
|
|
{ $$= new Item_func_mod($1,$3); }
|
|
|
|
| bit_expr '^' bit_expr
|
|
|
|
{ $$= new Item_func_bit_xor($1,$3); }
|
|
|
|
| simple_expr
|
|
|
|
;
|
2004-11-17 16:49:10 +01:00
|
|
|
|
|
|
|
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:
|
Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.
Let N be the number of expressions involved in a OR (respectively AND).
When N=1
For example, "select 1" involve only 1 term: there is no OR operator.
In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.
With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)
The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...
Considering that N=1 is by far the most probable expression,
this case should be optimal.
When N=2
For example, "select a OR b" involves 2 terms in the OR operator.
In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.
With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.
When N>=3
For example, "select a OR b OR c ...", which involves 3 or more terms.
In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.
With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.
This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation
Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.
For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.
2007-08-22 19:05:35 +02:00
|
|
|
INTERVAL_SYM expr %prec INTERVAL_SYM
|
|
|
|
{ $$=$2; }
|
2003-01-26 20:01:45 +01:00
|
|
|
;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
simple_expr:
|
|
|
|
simple_ident
|
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
|
|
|
{
|
2003-05-21 20:39:58 +02:00
|
|
|
$$= new Item_func_set_collation($1,
|
|
|
|
new Item_string($3.str,
|
|
|
|
$3.length,
|
2004-03-16 16:35:47 +01:00
|
|
|
YYTHD->charset()));
|
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
|
|
|
|
{ $$= new Item_func_concat($1, $3); }
|
|
|
|
| '+' simple_expr %prec NEG { $$= $2; }
|
|
|
|
| '-' simple_expr %prec NEG { $$= new Item_func_neg($2); }
|
|
|
|
| '~' simple_expr %prec NEG { $$= new Item_func_bit_neg($2); }
|
|
|
|
| not2 simple_expr %prec NEG { $$= negate_expression(YYTHD, $2); }
|
2006-08-31 17:00:25 +02:00
|
|
|
| '(' subselect ')'
|
|
|
|
{
|
|
|
|
$$= new Item_singlerow_subselect($2);
|
|
|
|
}
|
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);
|
|
|
|
$$= new Item_row(*$4);
|
|
|
|
}
|
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);
|
|
|
|
$$= new Item_row(*$5);
|
2002-11-15 19:32:09 +01:00
|
|
|
}
|
2006-08-31 17:00:25 +02:00
|
|
|
| EXISTS '(' subselect ')'
|
|
|
|
{
|
|
|
|
$$= new Item_exists_subselect($3);
|
|
|
|
}
|
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 ')'
|
2003-10-20 15:53:48 +02:00
|
|
|
{ $2->push_front($5);
|
2003-10-22 17:57:09 +02:00
|
|
|
Select->add_ftfunc_to_list((Item_func_match*)
|
|
|
|
($$=new Item_func_match(*$2,$6))); }
|
2002-12-19 06:38:26 +01:00
|
|
|
| ASCII_SYM '(' expr ')' { $$= new Item_func_ascii($3); }
|
2004-11-17 16:49:10 +01:00
|
|
|
| BINARY simple_expr %prec NEG
|
2003-03-04 16:53:53 +01:00
|
|
|
{
|
2007-05-09 21:17:21 +02:00
|
|
|
$$= create_func_cast($2, ITEM_CAST_CHAR, NULL, NULL, &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-09 21:17:21 +02:00
|
|
|
$$= create_func_cast($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
|
|
|
}
|
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
|
|
|
|
{ $$= new 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-09 21:17:21 +02:00
|
|
|
$$= create_func_cast($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 ')'
|
|
|
|
{ $$= new 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
|
|
|
}
|
2005-08-12 16:57:19 +02:00
|
|
|
$$= new 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 ')'
|
2005-08-12 16:57:19 +02:00
|
|
|
{ $$= new Item_insert_value(Lex->current_context(), $3); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| FUNC_ARG0 '(' ')'
|
2004-01-15 18:06:22 +01:00
|
|
|
{
|
|
|
|
if (!$1.symbol->create_func)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_FEATURE_DISABLED, MYF(0),
|
|
|
|
$1.symbol->group->name,
|
|
|
|
$1.symbol->group->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
|
|
|
}
|
|
|
|
$$= ((Item*(*)(void))($1.symbol->create_func))();
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| FUNC_ARG1 '(' expr ')'
|
2004-01-15 18:06:22 +01:00
|
|
|
{
|
|
|
|
if (!$1.symbol->create_func)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_FEATURE_DISABLED, MYF(0),
|
|
|
|
$1.symbol->group->name,
|
|
|
|
$1.symbol->group->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
|
|
|
}
|
|
|
|
$$= ((Item*(*)(Item*))($1.symbol->create_func))($3);
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| FUNC_ARG2 '(' expr ',' expr ')'
|
2004-01-15 18:06:22 +01:00
|
|
|
{
|
|
|
|
if (!$1.symbol->create_func)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_FEATURE_DISABLED, MYF(0),
|
|
|
|
$1.symbol->group->name,
|
|
|
|
$1.symbol->group->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
|
|
|
}
|
|
|
|
$$= ((Item*(*)(Item*,Item*))($1.symbol->create_func))($3,$5);
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| FUNC_ARG3 '(' expr ',' expr ',' expr ')'
|
2004-01-15 18:06:22 +01:00
|
|
|
{
|
|
|
|
if (!$1.symbol->create_func)
|
|
|
|
{
|
2004-11-13 18:35:51 +01:00
|
|
|
my_error(ER_FEATURE_DISABLED, MYF(0),
|
|
|
|
$1.symbol->group->name,
|
|
|
|
$1.symbol->group->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
|
|
|
}
|
|
|
|
$$= ((Item*(*)(Item*,Item*,Item*))($1.symbol->create_func))($3,$5,$7);
|
|
|
|
}
|
2003-06-23 09:56:44 +02:00
|
|
|
| ADDDATE_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$= new Item_date_add_interval($3, $5, INTERVAL_DAY, 0);}
|
|
|
|
| ADDDATE_SYM '(' expr ',' INTERVAL_SYM expr interval ')'
|
|
|
|
{ $$= new Item_date_add_interval($3, $6, $7, 0); }
|
2004-11-12 04:01:46 +01:00
|
|
|
| REPEAT_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_repeat($3,$5); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| ATAN '(' expr ')'
|
|
|
|
{ $$= new Item_func_atan($3); }
|
|
|
|
| ATAN '(' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_atan($3,$5); }
|
|
|
|
| CHAR_SYM '(' expr_list ')'
|
|
|
|
{ $$= new Item_func_char(*$3); }
|
2005-10-13 16:24:47 +02:00
|
|
|
| CHAR_SYM '(' expr_list USING charset_name ')'
|
|
|
|
{ $$= new Item_func_char(*$3, $5); }
|
2002-06-20 20:26:04 +02:00
|
|
|
| CHARSET '(' expr ')'
|
|
|
|
{ $$= new Item_func_charset($3); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| COALESCE '(' expr_list ')'
|
|
|
|
{ $$= new Item_func_coalesce(* $3); }
|
2003-02-27 13:53:10 +01:00
|
|
|
| COLLATION_SYM '(' expr ')'
|
|
|
|
{ $$= new Item_func_collation($3); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| CONCAT '(' expr_list ')'
|
|
|
|
{ $$= new Item_func_concat(* $3); }
|
|
|
|
| CONCAT_WS '(' expr ',' expr_list ')'
|
2004-10-28 08:43:31 +02:00
|
|
|
{ $5->push_front($3); $$= new Item_func_concat_ws(*$5); }
|
2004-08-10 10:42:31 +02:00
|
|
|
| CONVERT_TZ_SYM '(' expr ',' expr ',' expr ')'
|
|
|
|
{
|
2004-12-17 13:34:48 +01:00
|
|
|
if (Lex->add_time_zone_tables_to_query_tables(YYTHD))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_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-10 10:42:31 +02:00
|
|
|
$$= new Item_func_convert_tz($3, $5, $7);
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| CURDATE optional_braces
|
2003-08-11 21:43:01 +02:00
|
|
|
{ $$= new Item_func_curdate_local(); Lex->safe_to_cache_query=0; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| CURTIME optional_braces
|
2003-08-11 21:43:01 +02:00
|
|
|
{ $$= new Item_func_curtime_local(); Lex->safe_to_cache_query=0; }
|
2000-07-31 21:29:14 +02:00
|
|
|
| CURTIME '(' expr ')'
|
2002-12-04 23:14:51 +01:00
|
|
|
{
|
2003-08-11 21:43:01 +02:00
|
|
|
$$= new Item_func_curtime_local($3);
|
2002-11-22 14:50:53 +01:00
|
|
|
Lex->safe_to_cache_query=0;
|
2001-12-02 13:34:01 +01:00
|
|
|
}
|
2004-04-06 12:00:51 +02:00
|
|
|
| CURRENT_USER optional_braces
|
2006-07-02 12:35:45 +02:00
|
|
|
{
|
|
|
|
$$= new Item_func_current_user(Lex->current_context());
|
|
|
|
Lex->safe_to_cache_query= 0;
|
|
|
|
}
|
2003-01-26 20:01:45 +01:00
|
|
|
| DATE_ADD_INTERVAL '(' expr ',' interval_expr interval ')'
|
|
|
|
{ $$= new Item_date_add_interval($3,$5,$6,0); }
|
|
|
|
| DATE_SUB_INTERVAL '(' expr ',' interval_expr interval ')'
|
|
|
|
{ $$= new Item_date_add_interval($3,$5,$6,1); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| DATABASE '(' ')'
|
2002-12-04 23:14:51 +01:00
|
|
|
{
|
2001-12-02 13:34:01 +01:00
|
|
|
$$= new Item_func_database();
|
2002-12-04 23:14:51 +01:00
|
|
|
Lex->safe_to_cache_query=0;
|
2001-12-02 13:34:01 +01:00
|
|
|
}
|
2003-06-23 09:56:44 +02:00
|
|
|
| DATE_SYM '(' expr ')'
|
2003-07-08 12:06:05 +02:00
|
|
|
{ $$= new Item_date_typecast($3); }
|
2003-06-23 09:56:44 +02:00
|
|
|
| DAY_SYM '(' expr ')'
|
|
|
|
{ $$= new Item_func_dayofmonth($3); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| ELT_FUNC '(' expr ',' expr_list ')'
|
2003-07-15 15:11:49 +02:00
|
|
|
{ $5->push_front($3); $$= new Item_func_elt(*$5); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| MAKE_SET_SYM '(' expr ',' expr_list ')'
|
|
|
|
{ $$= new Item_func_make_set($3, *$5); }
|
2001-12-02 13:34:01 +01:00
|
|
|
| ENCRYPT '(' expr ')'
|
|
|
|
{
|
|
|
|
$$= new Item_func_encrypt($3);
|
2003-11-17 19:53:40 +01:00
|
|
|
Lex->uncacheable(UNCACHEABLE_RAND);
|
2001-12-02 13:34:01 +01:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| ENCRYPT '(' expr ',' expr ')' { $$= new Item_func_encrypt($3,$5); }
|
2003-04-08 11:38:17 +02:00
|
|
|
| DECODE_SYM '(' expr ',' TEXT_STRING_literal ')'
|
2000-07-31 21:29:14 +02:00
|
|
|
{ $$= new Item_func_decode($3,$5.str); }
|
2003-04-08 11:38:17 +02:00
|
|
|
| ENCODE_SYM '(' expr ',' TEXT_STRING_literal ')'
|
2000-07-31 21:29:14 +02:00
|
|
|
{ $$= new Item_func_encode($3,$5.str); }
|
2001-12-13 02:36:36 +01:00
|
|
|
| DES_DECRYPT_SYM '(' expr ')'
|
2001-12-13 01:31:19 +01:00
|
|
|
{ $$= new Item_func_des_decrypt($3); }
|
2001-12-13 02:36:36 +01:00
|
|
|
| DES_DECRYPT_SYM '(' expr ',' expr ')'
|
2001-12-13 01:31:19 +01:00
|
|
|
{ $$= new Item_func_des_decrypt($3,$5); }
|
2001-12-13 02:36:36 +01:00
|
|
|
| DES_ENCRYPT_SYM '(' expr ')'
|
2001-12-13 01:31:19 +01:00
|
|
|
{ $$= new Item_func_des_encrypt($3); }
|
2001-12-13 02:36:36 +01:00
|
|
|
| DES_ENCRYPT_SYM '(' expr ',' expr ')'
|
2001-12-13 01:31:19 +01:00
|
|
|
{ $$= new Item_func_des_encrypt($3,$5); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| EXPORT_SET '(' expr ',' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_export_set($3, $5, $7); }
|
|
|
|
| EXPORT_SET '(' expr ',' expr ',' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_export_set($3, $5, $7, $9); }
|
|
|
|
| EXPORT_SET '(' expr ',' expr ',' expr ',' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_export_set($3, $5, $7, $9, $11); }
|
|
|
|
| FORMAT_SYM '(' expr ',' NUM ')'
|
|
|
|
{ $$= new Item_func_format($3,atoi($5.str)); }
|
|
|
|
| FROM_UNIXTIME '(' expr ')'
|
|
|
|
{ $$= new Item_func_from_unixtime($3); }
|
|
|
|
| FROM_UNIXTIME '(' expr ',' expr ')'
|
|
|
|
{
|
2001-12-02 13:34:01 +01:00
|
|
|
$$= new Item_func_date_format (new Item_func_from_unixtime($3),$5,0);
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
| FIELD_FUNC '(' expr ',' expr_list ')'
|
2003-07-15 14:33:00 +02:00
|
|
|
{ $5->push_front($3); $$= new Item_func_field(*$5); }
|
2004-01-15 18:06:22 +01:00
|
|
|
| geometry_function
|
|
|
|
{
|
|
|
|
#ifdef HAVE_SPATIAL
|
|
|
|
$$= $1;
|
|
|
|
#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-11-03 13:01:59 +01:00
|
|
|
| GET_FORMAT '(' date_time_type ',' expr ')'
|
2003-10-20 10:24:18 +02:00
|
|
|
{ $$= new Item_func_get_format($3, $5); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| HOUR_SYM '(' expr ')'
|
|
|
|
{ $$= new Item_func_hour($3); }
|
|
|
|
| IF '(' expr ',' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_if($3,$5,$7); }
|
|
|
|
| INSERT '(' expr ',' expr ',' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_insert($3,$5,$7,$9); }
|
2003-01-26 20:01:45 +01:00
|
|
|
| interval_expr interval '+' expr
|
2000-07-31 21:29:14 +02:00
|
|
|
/* we cannot put interval before - */
|
2003-01-26 20:01:45 +01:00
|
|
|
{ $$= new Item_date_add_interval($4,$1,$2,0); }
|
|
|
|
| interval_expr
|
|
|
|
{
|
|
|
|
if ($1->type() != Item::ROW_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
|
|
|
my_parse_error(ER(ER_SYNTAX_ERROR));
|
|
|
|
MYSQL_YYABORT;
|
2003-01-26 20:01:45 +01:00
|
|
|
}
|
|
|
|
$$= new Item_func_interval((Item_row *)$1);
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| LAST_INSERT_ID '(' ')'
|
|
|
|
{
|
2004-03-25 17:42:13 +01:00
|
|
|
$$= new Item_func_last_insert_id();
|
2003-01-28 13:48:12 +01:00
|
|
|
Lex->safe_to_cache_query= 0;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
| LAST_INSERT_ID '(' expr ')'
|
|
|
|
{
|
2004-03-25 17:42:13 +01:00
|
|
|
$$= new Item_func_last_insert_id($3);
|
2003-01-28 13:48:12 +01:00
|
|
|
Lex->safe_to_cache_query= 0;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
|
|
|
| LEFT '(' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_left($3,$5); }
|
|
|
|
| LOCATE '(' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_locate($5,$3); }
|
|
|
|
| LOCATE '(' expr ',' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_locate($5,$3,$7); }
|
2002-02-28 14:28:36 +01:00
|
|
|
| GREATEST_SYM '(' expr ',' expr_list ')'
|
2000-07-31 21:29:14 +02:00
|
|
|
{ $5->push_front($3); $$= new Item_func_max(*$5); }
|
|
|
|
| LEAST_SYM '(' expr ',' expr_list ')'
|
|
|
|
{ $5->push_front($3); $$= new Item_func_min(*$5); }
|
2002-07-17 10:11:48 +02:00
|
|
|
| LOG_SYM '(' expr ')'
|
2002-08-30 11:40:40 +02:00
|
|
|
{ $$= new Item_func_log($3); }
|
2002-07-17 10:11:48 +02:00
|
|
|
| LOG_SYM '(' expr ',' expr ')'
|
2002-08-30 11:40:40 +02:00
|
|
|
{ $$= new Item_func_log($3, $5); }
|
2003-01-25 14:07:51 +01:00
|
|
|
| MASTER_POS_WAIT '(' expr ',' expr ')'
|
2003-08-11 21:44:43 +02:00
|
|
|
{
|
2003-01-25 14:07:51 +01:00
|
|
|
$$= new Item_master_pos_wait($3, $5);
|
2003-08-11 21:44:43 +02:00
|
|
|
Lex->safe_to_cache_query=0;
|
2003-02-04 20:52:14 +01:00
|
|
|
}
|
2003-01-25 14:07:51 +01:00
|
|
|
| MASTER_POS_WAIT '(' expr ',' expr ',' expr ')'
|
2003-08-11 21:44:43 +02:00
|
|
|
{
|
2003-01-25 14:07:51 +01:00
|
|
|
$$= new Item_master_pos_wait($3, $5, $7);
|
2003-08-11 21:44:43 +02:00
|
|
|
Lex->safe_to_cache_query=0;
|
2003-01-25 14:07:51 +01:00
|
|
|
}
|
2003-06-23 09:56:44 +02:00
|
|
|
| MICROSECOND_SYM '(' expr ')'
|
|
|
|
{ $$= new Item_func_microsecond($3); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| MINUTE_SYM '(' expr ')'
|
|
|
|
{ $$= new Item_func_minute($3); }
|
2002-11-21 01:07:14 +01:00
|
|
|
| MOD_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$ = new Item_func_mod( $3, $5); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| MONTH_SYM '(' expr ')'
|
|
|
|
{ $$= new Item_func_month($3); }
|
|
|
|
| NOW_SYM optional_braces
|
2003-08-11 21:43:01 +02:00
|
|
|
{ $$= new Item_func_now_local(); Lex->safe_to_cache_query=0;}
|
2000-07-31 21:29:14 +02:00
|
|
|
| NOW_SYM '(' expr ')'
|
2003-08-11 21:43:01 +02:00
|
|
|
{ $$= new Item_func_now_local($3); Lex->safe_to_cache_query=0;}
|
2001-12-02 13:34:01 +01:00
|
|
|
| PASSWORD '(' expr ')'
|
2003-07-01 21:40:59 +02:00
|
|
|
{
|
2003-07-08 00:36:14 +02:00
|
|
|
$$= YYTHD->variables.old_passwords ?
|
|
|
|
(Item *) new Item_func_old_password($3) :
|
2003-07-04 18:52:04 +02:00
|
|
|
(Item *) new Item_func_password($3);
|
|
|
|
}
|
|
|
|
| OLD_PASSWORD '(' expr ')'
|
|
|
|
{ $$= new Item_func_old_password($3); }
|
2004-11-17 16:49:10 +01:00
|
|
|
| POSITION_SYM '(' bit_expr IN_SYM expr ')'
|
2000-07-31 21:29:14 +02:00
|
|
|
{ $$ = new Item_func_locate($5,$3); }
|
2004-11-12 04:01:46 +01:00
|
|
|
| QUARTER_SYM '(' expr ')'
|
|
|
|
{ $$ = new Item_func_quarter($3); }
|
2001-12-02 13:34:01 +01:00
|
|
|
| RAND '(' expr ')'
|
2003-11-17 19:53:40 +01:00
|
|
|
{ $$= new Item_func_rand($3); Lex->uncacheable(UNCACHEABLE_RAND);}
|
2001-12-02 13:34:01 +01:00
|
|
|
| RAND '(' ')'
|
2003-11-17 19:53:40 +01:00
|
|
|
{ $$= new Item_func_rand(); Lex->uncacheable(UNCACHEABLE_RAND);}
|
2000-07-31 21:29:14 +02:00
|
|
|
| REPLACE '(' expr ',' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_replace($3,$5,$7); }
|
|
|
|
| RIGHT '(' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_right($3,$5); }
|
|
|
|
| ROUND '(' expr ')'
|
|
|
|
{ $$= new Item_func_round($3, new Item_int((char*)"0",0,1),0); }
|
|
|
|
| ROUND '(' expr ',' expr ')' { $$= new Item_func_round($3,$5,0); }
|
2004-11-12 04:01:46 +01:00
|
|
|
| ROW_COUNT_SYM '(' ')'
|
|
|
|
{
|
|
|
|
$$= new Item_func_row_count();
|
|
|
|
Lex->safe_to_cache_query= 0;
|
|
|
|
}
|
2003-06-23 09:56:44 +02:00
|
|
|
| SUBDATE_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$= new Item_date_add_interval($3, $5, INTERVAL_DAY, 1);}
|
|
|
|
| SUBDATE_SYM '(' expr ',' INTERVAL_SYM expr interval ')'
|
|
|
|
{ $$= new Item_date_add_interval($3, $6, $7, 1); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| SECOND_SYM '(' expr ')'
|
|
|
|
{ $$= new Item_func_second($3); }
|
|
|
|
| SUBSTRING '(' expr ',' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_substr($3,$5,$7); }
|
|
|
|
| SUBSTRING '(' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_substr($3,$5); }
|
|
|
|
| SUBSTRING '(' expr FROM expr FOR_SYM expr ')'
|
|
|
|
{ $$= new Item_func_substr($3,$5,$7); }
|
|
|
|
| SUBSTRING '(' expr FROM expr ')'
|
|
|
|
{ $$= new Item_func_substr($3,$5); }
|
|
|
|
| SUBSTRING_INDEX '(' expr ',' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_substr_index($3,$5,$7); }
|
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)
|
|
|
|
$$= new Item_func_sysdate_local();
|
|
|
|
else $$= new Item_func_now_local();
|
|
|
|
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)
|
|
|
|
$$= new Item_func_sysdate_local($3);
|
|
|
|
else $$= new Item_func_now_local($3);
|
|
|
|
Lex->safe_to_cache_query=0;
|
|
|
|
}
|
2003-06-23 09:56:44 +02:00
|
|
|
| TIME_SYM '(' expr ')'
|
2003-07-08 12:06:05 +02:00
|
|
|
{ $$= new Item_time_typecast($3); }
|
|
|
|
| TIMESTAMP '(' expr ')'
|
|
|
|
{ $$= new Item_datetime_typecast($3); }
|
2003-06-23 09:56:44 +02:00
|
|
|
| TIMESTAMP '(' expr ',' expr ')'
|
2003-07-08 12:06:05 +02:00
|
|
|
{ $$= new Item_func_add_time($3, $5, 1, 0); }
|
2004-11-12 04:01:46 +01:00
|
|
|
| TIMESTAMP_ADD '(' interval_time_st ',' expr ',' expr ')'
|
|
|
|
{ $$= new Item_date_add_interval($7,$5,$3,0); }
|
|
|
|
| TIMESTAMP_DIFF '(' interval_time_st ',' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_timestamp_diff($5,$7,$3); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| TRIM '(' expr ')'
|
2003-06-03 13:57:14 +02:00
|
|
|
{ $$= new Item_func_trim($3); }
|
|
|
|
| TRIM '(' LEADING expr FROM expr ')'
|
2000-07-31 21:29:14 +02:00
|
|
|
{ $$= new Item_func_ltrim($6,$4); }
|
2003-06-03 13:57:14 +02:00
|
|
|
| TRIM '(' TRAILING expr FROM expr ')'
|
2000-07-31 21:29:14 +02:00
|
|
|
{ $$= new Item_func_rtrim($6,$4); }
|
2003-06-03 13:57:14 +02:00
|
|
|
| TRIM '(' BOTH expr FROM expr ')'
|
2000-07-31 21:29:14 +02:00
|
|
|
{ $$= new Item_func_trim($6,$4); }
|
2003-06-03 13:57:14 +02:00
|
|
|
| TRIM '(' LEADING FROM expr ')'
|
|
|
|
{ $$= new Item_func_ltrim($5); }
|
|
|
|
| TRIM '(' TRAILING FROM expr ')'
|
|
|
|
{ $$= new Item_func_rtrim($5); }
|
|
|
|
| TRIM '(' BOTH FROM expr ')'
|
|
|
|
{ $$= new Item_func_trim($5); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| TRIM '(' expr FROM expr ')'
|
|
|
|
{ $$= new Item_func_trim($5,$3); }
|
2000-11-13 22:55:10 +01:00
|
|
|
| TRUNCATE_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_round($3,$5,1); }
|
2006-10-24 14:26:41 +02:00
|
|
|
| ident '.' ident '(' opt_expr_list ')'
|
2000-07-31 21:29:14 +02:00
|
|
|
{
|
2005-04-15 11:06:25 +02:00
|
|
|
LEX *lex= Lex;
|
2007-03-27 18:31:44 +02:00
|
|
|
sp_name *name= new sp_name($1, $3, true);
|
2004-11-12 04:01:46 +01:00
|
|
|
|
|
|
|
name->init_qname(YYTHD);
|
2005-07-09 19:51:59 +02:00
|
|
|
sp_add_used_routine(lex, YYTHD, name, TYPE_ENUM_FUNCTION);
|
2004-11-12 04:01:46 +01:00
|
|
|
if ($5)
|
2005-08-12 16:57:19 +02:00
|
|
|
$$= new Item_func_sp(Lex->current_context(), name, *$5);
|
2000-07-31 21:29:14 +02:00
|
|
|
else
|
2005-08-12 16:57:19 +02:00
|
|
|
$$= new Item_func_sp(Lex->current_context(), name);
|
2005-04-15 11:06:25 +02:00
|
|
|
lex->safe_to_cache_query=0;
|
2000-07-31 21:29:14 +02:00
|
|
|
}
|
2005-09-20 11:28:23 +02:00
|
|
|
| IDENT_sys '('
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
|
|
|
#ifdef HAVE_DLOPEN
|
2005-09-20 11:28:23 +02:00
|
|
|
udf_func *udf= 0;
|
2006-10-24 14:26:41 +02:00
|
|
|
LEX *lex= Lex;
|
2005-09-20 11:28:23 +02:00
|
|
|
if (using_udf_functions &&
|
|
|
|
(udf= find_udf($1.str, $1.length)) &&
|
|
|
|
udf->type == UDFTYPE_AGGREGATE)
|
|
|
|
{
|
|
|
|
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;
|
2005-09-20 11:28:23 +02:00
|
|
|
}
|
|
|
|
}
|
2006-10-24 14:26:41 +02:00
|
|
|
lex->current_select->udf_list.push_front(udf);
|
2005-09-20 11:28:23 +02:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
udf_expr_list ')'
|
|
|
|
{
|
2006-12-14 23:51:37 +01:00
|
|
|
LEX *lex= Lex;
|
2005-09-20 11:28:23 +02:00
|
|
|
#ifdef HAVE_DLOPEN
|
2006-10-24 14:26:41 +02:00
|
|
|
udf_func *udf;
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2006-10-24 14:26:41 +02:00
|
|
|
if (NULL != (udf= lex->current_select->udf_list.pop()))
|
2004-11-12 04:01:46 +01:00
|
|
|
{
|
2005-09-20 11:28:23 +02:00
|
|
|
if (udf->type == UDFTYPE_AGGREGATE)
|
|
|
|
Select->in_sum_expr--;
|
|
|
|
|
2004-11-12 04:01:46 +01:00
|
|
|
switch (udf->returns) {
|
|
|
|
case STRING_RESULT:
|
|
|
|
if (udf->type == UDFTYPE_FUNCTION)
|
|
|
|
{
|
2005-09-20 11:28:23 +02:00
|
|
|
if ($4 != NULL)
|
|
|
|
$$ = new Item_func_udf_str(udf, *$4);
|
2004-11-12 04:01:46 +01:00
|
|
|
else
|
|
|
|
$$ = new Item_func_udf_str(udf);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2005-09-20 11:28:23 +02:00
|
|
|
if ($4 != NULL)
|
|
|
|
$$ = new Item_sum_udf_str(udf, *$4);
|
2004-11-12 04:01:46 +01:00
|
|
|
else
|
|
|
|
$$ = new Item_sum_udf_str(udf);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case REAL_RESULT:
|
|
|
|
if (udf->type == UDFTYPE_FUNCTION)
|
|
|
|
{
|
2005-09-20 11:28:23 +02:00
|
|
|
if ($4 != NULL)
|
|
|
|
$$ = new Item_func_udf_float(udf, *$4);
|
2004-11-12 04:01:46 +01:00
|
|
|
else
|
|
|
|
$$ = new Item_func_udf_float(udf);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2005-09-20 11:28:23 +02:00
|
|
|
if ($4 != NULL)
|
|
|
|
$$ = new Item_sum_udf_float(udf, *$4);
|
2004-11-12 04:01:46 +01:00
|
|
|
else
|
|
|
|
$$ = new Item_sum_udf_float(udf);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case INT_RESULT:
|
|
|
|
if (udf->type == UDFTYPE_FUNCTION)
|
|
|
|
{
|
2005-09-20 11:28:23 +02:00
|
|
|
if ($4 != NULL)
|
|
|
|
$$ = new Item_func_udf_int(udf, *$4);
|
2004-11-12 04:01:46 +01:00
|
|
|
else
|
|
|
|
$$ = new Item_func_udf_int(udf);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2005-09-20 11:28:23 +02:00
|
|
|
if ($4 != NULL)
|
|
|
|
$$ = new Item_sum_udf_int(udf, *$4);
|
2004-11-12 04:01:46 +01:00
|
|
|
else
|
|
|
|
$$ = new Item_sum_udf_int(udf);
|
|
|
|
}
|
|
|
|
break;
|
2005-02-08 23:50:45 +01:00
|
|
|
case DECIMAL_RESULT:
|
|
|
|
if (udf->type == UDFTYPE_FUNCTION)
|
|
|
|
{
|
2005-09-20 11:28:23 +02:00
|
|
|
if ($4 != NULL)
|
|
|
|
$$ = new Item_func_udf_decimal(udf, *$4);
|
2005-02-08 23:50:45 +01:00
|
|
|
else
|
|
|
|
$$ = new Item_func_udf_decimal(udf);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2005-09-20 11:28:23 +02:00
|
|
|
if ($4 != NULL)
|
|
|
|
$$ = new Item_sum_udf_decimal(udf, *$4);
|
2005-02-08 23:50:45 +01:00
|
|
|
else
|
|
|
|
$$ = new Item_sum_udf_decimal(udf);
|
|
|
|
}
|
|
|
|
break;
|
2004-11-12 04:01:46 +01:00
|
|
|
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
|
|
|
MYSQL_YYABORT;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif /* HAVE_DLOPEN */
|
|
|
|
{
|
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
|
|
|
THD *thd= lex->thd;
|
|
|
|
LEX_STRING db;
|
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
|
|
|
sp_name *name= 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 (name)
|
|
|
|
name->init_qname(thd);
|
2004-11-12 04:01:46 +01:00
|
|
|
|
2005-07-09 19:51:59 +02:00
|
|
|
sp_add_used_routine(lex, YYTHD, name, TYPE_ENUM_FUNCTION);
|
2005-09-20 11:28:23 +02:00
|
|
|
if ($4)
|
|
|
|
$$= new Item_func_sp(Lex->current_context(), name, *$4);
|
2004-11-12 04:01:46 +01:00
|
|
|
else
|
2005-08-12 16:57:19 +02:00
|
|
|
$$= new Item_func_sp(Lex->current_context(), name);
|
2007-06-18 23:55:12 +02:00
|
|
|
}
|
|
|
|
lex->safe_to_cache_query=0;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| UNIQUE_USERS '(' text_literal ',' NUM ',' NUM ',' expr_list ')'
|
2002-12-04 23:14:51 +01:00
|
|
|
{
|
2001-12-02 13:34:01 +01:00
|
|
|
$$= new Item_func_unique_users($3,atoi($5.str),atoi($7.str), * $9);
|
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| UNIX_TIMESTAMP '(' ')'
|
2001-12-02 13:34:01 +01:00
|
|
|
{
|
|
|
|
$$= new Item_func_unix_timestamp();
|
2002-11-22 14:50:53 +01:00
|
|
|
Lex->safe_to_cache_query=0;
|
2001-12-02 13:34:01 +01:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| UNIX_TIMESTAMP '(' expr ')'
|
|
|
|
{ $$= new Item_func_unix_timestamp($3); }
|
|
|
|
| USER '(' ')'
|
2006-07-02 12:35:45 +02:00
|
|
|
{ $$= new Item_func_user(); Lex->safe_to_cache_query=0; }
|
2003-08-11 21:43:01 +02:00
|
|
|
| UTC_DATE_SYM optional_braces
|
|
|
|
{ $$= new Item_func_curdate_utc(); Lex->safe_to_cache_query=0;}
|
|
|
|
| UTC_TIME_SYM optional_braces
|
|
|
|
{ $$= new Item_func_curtime_utc(); Lex->safe_to_cache_query=0;}
|
|
|
|
| UTC_TIMESTAMP_SYM optional_braces
|
|
|
|
{ $$= new Item_func_now_utc(); Lex->safe_to_cache_query=0;}
|
2000-07-31 21:29:14 +02:00
|
|
|
| WEEK_SYM '(' expr ')'
|
2003-08-11 21:44:43 +02:00
|
|
|
{
|
2003-02-19 13:05:35 +01:00
|
|
|
$$= new Item_func_week($3,new Item_int((char*) "0",
|
2003-08-11 21:44:43 +02:00
|
|
|
YYTHD->variables.default_week_format,1));
|
2003-02-19 13:05:35 +01:00
|
|
|
}
|
2000-07-31 21:29:14 +02:00
|
|
|
| WEEK_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_week($3,$5); }
|
|
|
|
| YEAR_SYM '(' expr ')'
|
|
|
|
{ $$= new Item_func_year($3); }
|
|
|
|
| YEARWEEK '(' expr ')'
|
|
|
|
{ $$= new Item_func_yearweek($3,new Item_int((char*) "0",0,1)); }
|
|
|
|
| YEARWEEK '(' expr ',' expr ')'
|
|
|
|
{ $$= new Item_func_yearweek($3, $5); }
|
2005-04-04 00:50:05 +02:00
|
|
|
| BENCHMARK_SYM '(' ulong_num ',' expr ')'
|
2002-12-04 23:14:51 +01:00
|
|
|
{
|
2001-12-02 13:34:01 +01:00
|
|
|
$$=new Item_func_benchmark($3,$5);
|
2003-11-18 21:04:01 +01:00
|
|
|
Lex->uncacheable(UNCACHEABLE_SIDEEFFECT);
|
2001-12-02 13:34:01 +01:00
|
|
|
}
|
2000-08-21 23:39:08 +02:00
|
|
|
| EXTRACT_SYM '(' interval FROM expr ')'
|
2002-04-16 01:09:30 +02:00
|
|
|
{ $$=new Item_extract( $3, $5); };
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2004-01-15 18:06:22 +01:00
|
|
|
geometry_function:
|
2005-02-19 10:51:49 +01:00
|
|
|
CONTAINS_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_spatial_rel($3, $5, Item_func::SP_CONTAINS_FUNC)); }
|
|
|
|
| GEOMFROMTEXT '(' expr ')'
|
2004-01-15 18:06:22 +01:00
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3)); }
|
|
|
|
| GEOMFROMTEXT '(' expr ',' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3, $5)); }
|
|
|
|
| GEOMFROMWKB '(' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_wkb($3)); }
|
|
|
|
| GEOMFROMWKB '(' expr ',' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_wkb($3, $5)); }
|
|
|
|
| GEOMETRYCOLLECTION '(' expr_list ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_spatial_collection(* $3,
|
2004-03-12 09:04:00 +01:00
|
|
|
Geometry::wkb_geometrycollection,
|
|
|
|
Geometry::wkb_point)); }
|
2004-01-15 18:06:22 +01:00
|
|
|
| LINESTRING '(' expr_list ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_spatial_collection(* $3,
|
2004-03-12 09:04:00 +01:00
|
|
|
Geometry::wkb_linestring, Geometry::wkb_point)); }
|
2004-01-15 18:06:22 +01:00
|
|
|
| MULTILINESTRING '(' expr_list ')'
|
|
|
|
{ $$= GEOM_NEW( Item_func_spatial_collection(* $3,
|
2004-03-12 09:04:00 +01:00
|
|
|
Geometry::wkb_multilinestring, Geometry::wkb_linestring)); }
|
2004-01-15 18:06:22 +01:00
|
|
|
| MLINEFROMTEXT '(' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3)); }
|
|
|
|
| MLINEFROMTEXT '(' expr ',' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3, $5)); }
|
|
|
|
| MPOINTFROMTEXT '(' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3)); }
|
|
|
|
| MPOINTFROMTEXT '(' expr ',' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3, $5)); }
|
|
|
|
| MPOLYFROMTEXT '(' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3)); }
|
|
|
|
| MPOLYFROMTEXT '(' expr ',' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3, $5)); }
|
|
|
|
| MULTIPOINT '(' expr_list ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_spatial_collection(* $3,
|
2004-03-12 09:04:00 +01:00
|
|
|
Geometry::wkb_multipoint, Geometry::wkb_point)); }
|
2004-01-15 18:06:22 +01:00
|
|
|
| MULTIPOLYGON '(' expr_list ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_spatial_collection(* $3,
|
2004-03-12 09:04:00 +01:00
|
|
|
Geometry::wkb_multipolygon, Geometry::wkb_polygon)); }
|
2004-01-15 18:06:22 +01:00
|
|
|
| POINT_SYM '(' expr ',' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_point($3,$5)); }
|
|
|
|
| POINTFROMTEXT '(' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3)); }
|
|
|
|
| POINTFROMTEXT '(' expr ',' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3, $5)); }
|
|
|
|
| POLYFROMTEXT '(' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3)); }
|
|
|
|
| POLYFROMTEXT '(' expr ',' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3, $5)); }
|
|
|
|
| POLYGON '(' expr_list ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_spatial_collection(* $3,
|
2004-03-12 09:04:00 +01:00
|
|
|
Geometry::wkb_polygon, Geometry::wkb_linestring)); }
|
2004-01-15 18:06:22 +01:00
|
|
|
| GEOMCOLLFROMTEXT '(' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3)); }
|
|
|
|
| GEOMCOLLFROMTEXT '(' expr ',' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3, $5)); }
|
|
|
|
| LINEFROMTEXT '(' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3)); }
|
|
|
|
| LINEFROMTEXT '(' expr ',' expr ')'
|
|
|
|
{ $$= GEOM_NEW(Item_func_geometry_from_text($3, $5)); }
|
|
|
|
;
|
|
|
|
|
2003-10-22 17:57:09 +02:00
|
|
|
fulltext_options:
|
|
|
|
/* nothing */ { $$= FT_NL; }
|
|
|
|
| WITH QUERY_SYM EXPANSION_SYM { $$= FT_NL | FT_EXPAND; }
|
|
|
|
| IN_SYM BOOLEAN_SYM MODE_SYM { $$= FT_BOOL; }
|
|
|
|
;
|
|
|
|
|
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
|
|
|
udf_func *udf= Select->udf_list.head();
|
|
|
|
/*
|
|
|
|
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
|
|
|
{
|
2006-10-24 14:26:41 +02:00
|
|
|
if (!udf)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
Disallow using AS to specify explicit names for the arguments
|
|
|
|
of stored routine calls
|
|
|
|
*/
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_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-24 14:26:41 +02:00
|
|
|
}
|
|
|
|
|
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-10-24 14:26:41 +02:00
|
|
|
else if (udf)
|
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
|
|
|
| GROUP_UNIQUE_USERS '(' text_literal ',' NUM ',' NUM ',' in_sum_expr ')'
|
|
|
|
{ $$= new Item_sum_unique_users($3,atoi($5.str),atoi($7.str),$9); }
|
|
|
|
| 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
|
|
|
|
no sence inside MIN and MAX grouping functions; so MIN|MAX(DISTINCT ...)
|
|
|
|
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;}
|
|
|
|
;
|
|
|
|
|
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
|
|
|
*/
|
2007-07-24 00:23:35 +02:00
|
|
|
table_ref normal_join table_ref %prec TABLE_REF_PRIORITY
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_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-06-10 18:02:19 +02: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;
|
2001-06-15 04:03:15 +02:00
|
|
|
sel->use_index_ptr=sel->ignore_index_ptr=0;
|
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
|
|
|
{
|
2002-11-23 17:54:15 +01:00
|
|
|
LEX *lex= Lex;
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel= lex->current_select;
|
2003-01-09 02:55:26 +01:00
|
|
|
if (!($$= sel->add_table_to_list(lex->thd, $2, $3,
|
2003-01-09 21:42:31 +01:00
|
|
|
sel->get_table_join_options(),
|
2002-12-06 20:11:27 +01:00
|
|
|
lex->lock_option,
|
2002-10-30 12:18:52 +01:00
|
|
|
sel->get_use_index(),
|
|
|
|
sel->get_ignore_index())))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_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
|
|
|
sel->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,
|
|
|
|
TL_READ,(List<String> *)0,
|
|
|
|
(List<String> *)0)))
|
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;
|
2006-03-06 18:26:39 +01:00
|
|
|
if (lex->sql_command == (int)SQLCOM_HA_READ ||
|
2007-06-06 15:29:15 +02:00
|
|
|
lex->sql_command == (int)SQLCOM_KILL ||
|
|
|
|
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-09 14:20:06 +01:00
|
|
|
opt_for_join:
|
|
|
|
/* empty */
|
|
|
|
| FOR_SYM JOIN_SYM;
|
|
|
|
|
2000-07-31 21:29:14 +02:00
|
|
|
opt_key_definition:
|
|
|
|
/* empty */ {}
|
|
|
|
| USE_SYM key_usage_list
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel= Select;
|
2001-06-15 04:03:15 +02:00
|
|
|
sel->use_index= *$2;
|
|
|
|
sel->use_index_ptr= &sel->use_index;
|
|
|
|
}
|
2003-01-09 21:42:31 +01:00
|
|
|
| FORCE_SYM key_usage_list
|
|
|
|
{
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel= Select;
|
2003-01-09 21:42:31 +01:00
|
|
|
sel->use_index= *$2;
|
|
|
|
sel->use_index_ptr= &sel->use_index;
|
|
|
|
sel->table_join_options|= TL_OPTION_FORCE_INDEX;
|
|
|
|
}
|
2007-03-26 15:52:52 +02:00
|
|
|
| IGNORE_SYM key_usage_list
|
2001-06-15 04:03:15 +02:00
|
|
|
{
|
2003-07-03 01:30:52 +02:00
|
|
|
SELECT_LEX *sel= Select;
|
2007-03-26 15:52:52 +02:00
|
|
|
sel->ignore_index= *$2;
|
2001-06-15 04:03:15 +02:00
|
|
|
sel->ignore_index_ptr= &sel->ignore_index;
|
2002-04-16 01:09:30 +02:00
|
|
|
};
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
key_usage_list:
|
2007-03-26 15:52:52 +02:00
|
|
|
key_or_index opt_for_join
|
2007-03-09 14:20:06 +01:00
|
|
|
{ Select->interval_list.empty(); }
|
2003-01-09 21:42:31 +01:00
|
|
|
'(' key_list_or_empty ')'
|
2003-07-03 01:30:52 +02:00
|
|
|
{ $$= &Select->interval_list; }
|
2003-01-09 21:42:31 +01:00
|
|
|
;
|
|
|
|
|
|
|
|
key_list_or_empty:
|
|
|
|
/* empty */ {}
|
|
|
|
| key_usage_list2 {}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
|
|
|
key_usage_list2:
|
|
|
|
key_usage_list2 ',' ident
|
2003-07-03 01:30:52 +02:00
|
|
|
{ Select->
|
2004-11-08 00:13:54 +01:00
|
|
|
interval_list.push_back(new (YYTHD->mem_root) String((const char*) $3.str, $3.length,
|
2003-06-03 11:59:17 +02:00
|
|
|
system_charset_info)); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| ident
|
2003-07-03 01:30:52 +02:00
|
|
|
{ Select->
|
2004-11-08 00:13:54 +01:00
|
|
|
interval_list.push_back(new (YYTHD->mem_root) String((const char*) $1.str, $1.length,
|
2003-06-03 11:59:17 +02:00
|
|
|
system_charset_info)); }
|
2000-07-31 21:29:14 +02:00
|
|
|
| PRIMARY_SYM
|
2003-07-03 01:30:52 +02:00
|
|
|
{ Select->
|
2004-11-08 00:13:54 +01:00
|
|
|
interval_list.push_back(new (YYTHD->mem_root) String("PRIMARY", 7,
|
2003-06-03 11:59:17 +02:00
|
|
|
system_charset_info)); };
|
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 */
|
2002-07-16 21:42:53 +02:00
|
|
|
| GROUP 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();
|
|
|
|
if (!first_sl->next_select() &&
|
|
|
|
(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); }
|
|
|
|
;
|
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
|
|
|
|
|
|
|
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;
|
|
|
|
lex->proc_list.next= (byte**) &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:
|
|
|
|
remember_name expr
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
|
|
|
|
|
|
|
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)
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
$2->set_name($1,(uint) ((char*) lip->tok_end - $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;
|
A fix and test cases for
Bug#4968 "Stored procedure crash if cursor opened on altered table"
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Test cases for bugs 4968, 19733, 6895 will be added 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 were not
re-execution friendly: during their operation they used to 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 (note that code in 5.1 already creates and
uses a copy of this structure in mysql_create_table()/alter_table(),
but this approach didn't work well for CREATE TABLE SELECT statement).
2006-12-08 00:20:09 +01: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;
|
|
|
|
lex->name=$4.str;
|
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;
|
|
|
|
}
|
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;
|
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
|
|
|
|
2007-09-03 11:55:35 +02:00
|
|
|
table_alias_ref_list:
|
|
|
|
table_alias_ref
|
|
|
|
| table_alias_ref_list ',' table_alias_ref;
|
|
|
|
|
|
|
|
table_alias_ref:
|
|
|
|
table_ident
|
|
|
|
{
|
|
|
|
if (!Select->add_table_to_list(YYTHD, $1, NULL,
|
|
|
|
TL_OPTION_UPDATING | TL_OPTION_ALIAS,
|
|
|
|
Lex->lock_option ))
|
|
|
|
MYSQL_YYABORT;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
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
|
|
|
}
|
2007-09-03 11:55:35 +02:00
|
|
|
| FROM table_alias_ref_list
|
2002-01-02 23:46:43 +01:00
|
|
|
{ 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;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_sql_command= SQLCOM_SHOW_DATABASES;
|
|
|
|
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;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_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;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_sql_command= SQLCOM_SHOW_TRIGGERS;
|
|
|
|
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
|
|
|
}
|
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;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_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;
|
2004-12-30 13:20:40 +01:00
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_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
|
|
|
}
|
2003-12-17 23:52:03 +01:00
|
|
|
| ENGINE_SYM storage_engines
|
2003-12-10 05:31:42 +01:00
|
|
|
{ Lex->create_info.db_type= $2; }
|
|
|
|
show_engine_param
|
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
|
|
|
{
|
2004-11-13 11:56:39 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_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;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_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;
|
|
|
|
WARN_DEPRECATED("SHOW TABLE TYPES", "SHOW [STORAGE] ENGINES");
|
|
|
|
}
|
|
|
|
| opt_storage ENGINES_SYM
|
|
|
|
{
|
|
|
|
LEX *lex=Lex;
|
|
|
|
lex->sql_command= SQLCOM_SHOW_STORAGE_ENGINES;
|
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;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_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;
|
2004-11-12 04:01:46 +01:00
|
|
|
}
|
2002-07-08 18:34:49 +02:00
|
|
|
| INNOBASE_SYM STATUS_SYM
|
2003-12-10 05:31:42 +01:00
|
|
|
{ Lex->sql_command = SQLCOM_SHOW_INNODB_STATUS; WARN_DEPRECATED("SHOW INNODB STATUS", "SHOW ENGINE INNODB STATUS"); }
|
2004-12-24 12:13:32 +01:00
|
|
|
| MUTEX_SYM STATUS_SYM
|
|
|
|
{ Lex->sql_command = SQLCOM_SHOW_MUTEX_STATUS; }
|
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;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_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;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_sql_command= SQLCOM_SHOW_CHARSETS;
|
|
|
|
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;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_sql_command= SQLCOM_SHOW_COLLATIONS;
|
|
|
|
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
|
|
|
}
|
2003-07-12 23:31:21 +02:00
|
|
|
| BERKELEY_DB_SYM LOGS_SYM
|
2003-12-10 05:31:42 +01:00
|
|
|
{ Lex->sql_command= SQLCOM_SHOW_LOGS; WARN_DEPRECATED("SHOW BDB LOGS", "SHOW ENGINE BDB LOGS"); }
|
2000-12-15 12:18:52 +01:00
|
|
|
| LOGS_SYM
|
2003-12-10 05:31:42 +01:00
|
|
|
{ Lex->sql_command= SQLCOM_SHOW_LOGS; WARN_DEPRECATED("SHOW LOGS", "SHOW ENGINE BDB LOGS"); }
|
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;
|
|
|
|
Lex->name=$4.str;
|
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;
|
|
|
|
}
|
|
|
|
| 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;
|
|
|
|
}
|
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;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_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;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_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
|
|
|
|
}
|
|
|
|
;
|
2000-07-31 21:29:14 +02:00
|
|
|
|
2003-12-10 05:31:42 +01:00
|
|
|
show_engine_param:
|
|
|
|
STATUS_SYM
|
|
|
|
{
|
|
|
|
switch (Lex->create_info.db_type) {
|
2005-09-19 15:35:07 +02:00
|
|
|
case DB_TYPE_NDBCLUSTER:
|
|
|
|
Lex->sql_command = SQLCOM_SHOW_NDBCLUSTER_STATUS;
|
|
|
|
break;
|
2003-12-10 05:31:42 +01:00
|
|
|
case DB_TYPE_INNODB:
|
|
|
|
Lex->sql_command = SQLCOM_SHOW_INNODB_STATUS;
|
|
|
|
break;
|
|
|
|
default:
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_NOT_SUPPORTED_YET, MYF(0), "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;
|
2003-12-10 05:31:42 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
| LOGS_SYM
|
|
|
|
{
|
|
|
|
switch (Lex->create_info.db_type) {
|
|
|
|
case DB_TYPE_BERKELEY_DB:
|
|
|
|
Lex->sql_command = SQLCOM_SHOW_LOGS;
|
|
|
|
break;
|
|
|
|
default:
|
2004-10-20 03:04:37 +02:00
|
|
|
my_error(ER_NOT_SUPPORTED_YET, MYF(0), "LOGS");
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_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-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;
|
|
|
|
lex->sql_command= SQLCOM_SELECT;
|
|
|
|
lex->orig_sql_command= SQLCOM_SHOW_FIELDS;
|
|
|
|
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; }
|
|
|
|
;
|
|
|
|
|
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-03-06 20:53:14 +01:00
|
|
|
KILL_SYM { Lex->sql_command= SQLCOM_KILL; } 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-03-06 20:53:14 +01:00
|
|
|
lex->value_list.push_front($4);
|
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
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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 I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
lex->fname_start= lip->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;
|
|
|
|
if (lex->sphead)
|
|
|
|
{
|
|
|
|
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;
|
2006-09-11 14:45:40 +02:00
|
|
|
WARN_DEPRECATED("LOAD TABLE FROM MASTER",
|
2006-09-11 13:50:41 +02:00
|
|
|
"mysqldump or future "
|
|
|
|
"BACKUP/RESTORE DATABASE facility");
|
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-02-14 05:24:01 +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
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
THD *thd= YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
Lex_input_stream *lip= thd->m_lip;
|
|
|
|
lex->fname_end= lip->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 14:45:40 +02:00
|
|
|
WARN_DEPRECATED("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:
|
2007-08-03 12:25:23 +02:00
|
|
|
TEXT_STRING
|
|
|
|
{
|
|
|
|
LEX_STRING tmp;
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
CHARSET_INFO *cs_con= thd->variables.collation_connection;
|
|
|
|
CHARSET_INFO *cs_cli= thd->variables.character_set_client;
|
|
|
|
uint repertoire= thd->lex->text_string_is_7bit &&
|
|
|
|
my_charset_is_ascii_based(cs_cli) ?
|
|
|
|
MY_REPERTOIRE_ASCII : MY_REPERTOIRE_UNICODE30;
|
|
|
|
if (thd->charset_is_collation_connection ||
|
|
|
|
(repertoire == MY_REPERTOIRE_ASCII &&
|
|
|
|
my_charset_is_ascii_based(cs_con)))
|
|
|
|
tmp= $1;
|
|
|
|
else
|
|
|
|
thd->convert_string(&tmp, cs_con, $1.str, $1.length, cs_cli);
|
|
|
|
$$= new Item_string(tmp.str, tmp.length, cs_con,
|
|
|
|
DERIVATION_COERCIBLE, repertoire);
|
|
|
|
}
|
|
|
|
| NCHAR_STRING
|
|
|
|
{
|
|
|
|
uint repertoire= Lex->text_string_is_7bit ?
|
|
|
|
MY_REPERTOIRE_ASCII : MY_REPERTOIRE_UNICODE30;
|
|
|
|
DBUG_ASSERT(my_charset_is_ascii_based(national_charset_info));
|
|
|
|
$$= new Item_string($1.str, $1.length, national_charset_info,
|
|
|
|
DERIVATION_COERCIBLE, repertoire);
|
|
|
|
}
|
|
|
|
| UNDERSCORE_CHARSET TEXT_STRING
|
|
|
|
{
|
|
|
|
$$= new Item_string($2.str, $2.length, Lex->underscore_charset);
|
|
|
|
((Item_string*) $$)->set_repertoire_from_value();
|
|
|
|
}
|
|
|
|
| text_literal TEXT_STRING_literal
|
|
|
|
{
|
|
|
|
Item_string* item= (Item_string*) $1;
|
|
|
|
item->append($2.str, $2.length);
|
|
|
|
if (!(item->collation.repertoire & MY_REPERTOIRE_EXTENDED))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
If the string has been pure ASCII so far,
|
|
|
|
check the new part.
|
|
|
|
*/
|
|
|
|
CHARSET_INFO *cs= YYTHD->variables.collation_connection;
|
|
|
|
item->collation.repertoire|= my_string_repertoire(cs,
|
|
|
|
$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
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
THD *thd= YYTHD;
|
2004-03-02 20:39:50 +01:00
|
|
|
LEX *lex= thd->lex;
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
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 I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
item= new Item_param((uint) (lip->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; }
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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); }
|
2007-08-03 12:25:23 +02:00
|
|
|
| UNDERSCORE_CHARSET HEX_NUM
|
|
|
|
{
|
|
|
|
Item *tmp= new Item_hex_string($2.str, $2.length);
|
|
|
|
/*
|
|
|
|
it is OK only emulate fix_fieds, because we need only
|
2004-03-18 14:14:36 +01:00
|
|
|
value of constant
|
2007-08-03 12:25:23 +02:00
|
|
|
*/
|
|
|
|
String *str= tmp ?
|
|
|
|
tmp->quick_fix_field(), tmp->val_str((String*) 0) :
|
|
|
|
(String*) 0;
|
2007-10-11 13:07:10 +02:00
|
|
|
$$= new Item_string(NULL, /* name will be set in select_item */
|
|
|
|
str ? str->ptr() : "",
|
2007-08-03 12:25:23 +02:00
|
|
|
str ? str->length() : 0,
|
|
|
|
Lex->underscore_charset);
|
|
|
|
if ($$)
|
2007-10-11 13:07:10 +02:00
|
|
|
{
|
2007-08-03 12:25:23 +02:00
|
|
|
((Item_string *) $$)->set_repertoire_from_value();
|
2007-10-11 13:07:10 +02:00
|
|
|
if (!$$->check_well_formed_result(&$$->str_value))
|
|
|
|
{
|
|
|
|
$$= new Item_null();
|
|
|
|
$$->set_name(NULL, 0, system_charset_info);
|
|
|
|
}
|
|
|
|
}
|
2007-08-03 12:25:23 +02: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;
|
2007-10-11 13:07:10 +02:00
|
|
|
$$= new Item_string(NULL, /* name will be set in select_item */
|
|
|
|
str ? str->ptr() : "",
|
|
|
|
str ? str->length() : 0,
|
|
|
|
Lex->underscore_charset);
|
|
|
|
if ($$ && !$$->check_well_formed_result(&$$->str_value))
|
|
|
|
{
|
|
|
|
$$= new Item_null();
|
|
|
|
$$->set_name(NULL, 0, system_charset_info);
|
|
|
|
}
|
2004-12-17 15:06:05 +01:00
|
|
|
}
|
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
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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 I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
lip->tok_start_prev -
|
2007-07-30 01:35:16 +02:00
|
|
|
lex->sphead->m_tmp_query,
|
|
|
|
lip->tok_end - lip->tok_start_prev);
|
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.
|
|
|
|
*/
|
|
|
|
lex->trg_table_fields.link_in_list((byte *)trg_fld,
|
|
|
|
(byte**)&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;
|
|
|
|
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;
|
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;
|
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-02-14 05:24:01 +01:00
|
|
|
TEXT_STRING_filesystem:
|
|
|
|
TEXT_STRING
|
|
|
|
{
|
|
|
|
THD *thd= YYTHD;
|
|
|
|
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; }
|
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
|
|
|
|
2006-09-27 17:11:11 +02:00
|
|
|
if (check_string_length(&$$->user,
|
2006-09-08 13:16:39 +02:00
|
|
|
ER(ER_USERNAME), USERNAME_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;
|
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
|
|
|
|
2006-09-27 17:11:11 +02:00
|
|
|
if (check_string_length(&$$->user,
|
2006-09-08 13:16:39 +02:00
|
|
|
ER(ER_USERNAME), USERNAME_LENGTH) ||
|
2006-09-27 17:11:11 +02:00
|
|
|
check_string_length(&$$->host,
|
2006-09-08 13:16:39 +02:00
|
|
|
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 {}
|
|
|
|
| LANGUAGE_SYM {}
|
|
|
|
| NO_SYM {}
|
|
|
|
| OPEN_SYM {}
|
|
|
|
| PREPARE_SYM {}
|
|
|
|
| REPAIR {}
|
|
|
|
| RESET_SYM {}
|
|
|
|
| RESTORE_SYM {}
|
|
|
|
| ROLLBACK_SYM {}
|
|
|
|
| SAVEPOINT_SYM {}
|
|
|
|
| SECURITY_SYM {}
|
|
|
|
| SIGNED_SYM {}
|
|
|
|
| SLAVE {}
|
|
|
|
| START_SYM {}
|
|
|
|
| STOP_SYM {}
|
|
|
|
| TRUNCATE_SYM {}
|
|
|
|
| UNICODE_SYM {}
|
|
|
|
| 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 {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| AUTO_INC {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| AVG_ROW_LENGTH {}
|
|
|
|
| AVG_SYM {}
|
2000-10-20 16:39:23 +02:00
|
|
|
| BERKELEY_DB_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-11-17 11:11:48 +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 {}
|
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 {}
|
2002-07-20 13:51:52 +02:00
|
|
|
| CUBE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| DATA_SYM {}
|
|
|
|
| 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 {}
|
2003-10-14 00:52:03 +02:00
|
|
|
| DISCARD {}
|
2003-01-21 20:07:59 +01:00
|
|
|
| DUMPFILE {}
|
|
|
|
| DUPLICATE_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| DYNAMIC_SYM {}
|
|
|
|
| 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 {}
|
2001-10-24 19:52:19 +02:00
|
|
|
| EVENTS_SYM {}
|
2003-10-23 15:21:06 +02:00
|
|
|
| EXPANSION_SYM {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| EXTENDED_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
|
|
|
| DISABLE_SYM {}
|
|
|
|
| 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 {}
|
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 {}
|
2003-04-16 08:25:43 +02:00
|
|
|
| RELAY_THREAD {}
|
2001-04-07 00:18:33 +02:00
|
|
|
| LAST_SYM {}
|
2003-06-12 13:29:02 +02:00
|
|
|
| LEAVES {}
|
2001-03-21 00:02:22 +01:00
|
|
|
| LEVEL_SYM {}
|
2003-02-11 12:39:14 +01:00
|
|
|
| LINESTRING {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| LOCAL_SYM {}
|
2001-08-21 19:06:00 +02:00
|
|
|
| LOCKS_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 {}
|
|
|
|
| MAX_UPDATES_PER_HOUR {}
|
2004-12-29 18:30:37 +01:00
|
|
|
| MAX_USER_CONNECTIONS_SYM {}
|
2001-01-16 14:02:25 +01:00
|
|
|
| MEDIUM_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 {}
|
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 {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| PASSWORD {}
|
2005-01-16 13:16:23 +01:00
|
|
|
| PHASE_SYM {}
|
2003-02-20 23:14:37 +01:00
|
|
|
| POINT_SYM {}
|
2003-02-11 12:39:14 +01:00
|
|
|
| POLYGON {}
|
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 {}
|
2002-08-30 11:40:40 +02:00
|
|
|
| RAID_0_SYM {}
|
2000-08-21 23:39:08 +02:00
|
|
|
| RAID_CHUNKS {}
|
|
|
|
| RAID_CHUNKSIZE {}
|
2002-08-30 11:40:40 +02:00
|
|
|
| RAID_STRIPED_SYM {}
|
2000-08-21 23:39:08 +02:00
|
|
|
| RAID_TYPE {}
|
2005-01-16 13:16:23 +01:00
|
|
|
| RECOVER_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 {}
|
2000-07-31 21:29:14 +02:00
|
|
|
| RELOAD {}
|
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 {}
|
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 {}
|
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 {}
|
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 {}
|
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 {}
|
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 {}
|
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:
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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?
|
|
|
|
*/
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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 I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
lex->sphead->m_tmp_query= lip->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
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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 I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
qbuff.length= lip->ptr - sp->m_tmp_query;
|
2005-03-04 14:35:28 +01:00
|
|
|
else
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
qbuff.length= lip->tok_end - sp->m_tmp_query;
|
2005-05-17 17:08:43 +02:00
|
|
|
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
if (!(qbuff.str= alloc_root(thd->mem_root, 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
|
|
|
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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);
|
|
|
|
}
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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-05-18 09:47:45 +02:00
|
|
|
if ($2.var == &trg_new_row_fake_var)
|
|
|
|
{
|
|
|
|
/* 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.
|
|
|
|
*/
|
2005-05-27 12:15:17 +02:00
|
|
|
lex->trg_table_fields.link_in_list((byte *)trg_fld,
|
|
|
|
(byte **)&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-08-08 16:04:10 +02:00
|
|
|
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,
|
|
|
|
find_sys_var("tx_isolation"),
|
|
|
|
&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;
|
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-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
|
|
|
{
|
2002-11-26 14:18:16 +01:00
|
|
|
THD *thd=YYTHD;
|
2002-07-23 17:31:22 +02:00
|
|
|
LEX_USER *user;
|
2005-10-11 15:01:38 +02:00
|
|
|
LEX *lex= Lex;
|
|
|
|
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
|
|
|
|
{
|
2004-11-12 04:01:46 +01:00
|
|
|
LEX *lex= Lex;
|
|
|
|
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 */
|
|
|
|
sys_var *tmp=find_sys_var($1.str, $1.length);
|
|
|
|
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;
|
2004-11-12 04:01:46 +01:00
|
|
|
/*
|
|
|
|
If this is time_zone variable we should open time zone
|
|
|
|
describing tables
|
|
|
|
*/
|
2004-12-17 13:34:48 +01:00
|
|
|
if (tmp == &sys_time_zone &&
|
|
|
|
lex->add_time_zone_tables_to_query_tables(YYTHD))
|
A fix for Bug#26750 "valgrind leak in sp_head" (and post-review
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_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 10:54:02 +02:00
|
|
|
else if (spc && tmp == &sys_autocommit)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
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 */
|
|
|
|
$$.var= &trg_new_row_fake_var;
|
|
|
|
$$.base_name= $3;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
sys_var *tmp=find_sys_var($3.str, $3.length);
|
|
|
|
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
|
|
|
|
{
|
|
|
|
sys_var *tmp=find_sys_var($3.str, $3.length);
|
|
|
|
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
|
|
|
}
|
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
|
|
|
}
|
2003-02-12 20:55:37 +01:00
|
|
|
handler_read_or_scan where_clause opt_limit_clause {}
|
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; }
|
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;
|
2007-07-05 09:34:04 +02:00
|
|
|
if (lex->copy_db_to(&lex->current_select->db, 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;
|
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;
|
2006-03-06 18:26:39 +01:00
|
|
|
if (lex->sql_command == (int)SQLCOM_HA_READ ||
|
2007-06-06 15:29:15 +02:00
|
|
|
lex->sql_command == (int)SQLCOM_KILL ||
|
|
|
|
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.
|
|
|
|
|
|
|
|
**************************************************************************/
|
|
|
|
|
|
|
|
view_or_trigger_or_sp:
|
|
|
|
definer view_or_trigger_or_sp_tail
|
|
|
|
{}
|
|
|
|
| view_replace_or_algorithm definer view_tail
|
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
|
|
|
view_or_trigger_or_sp_tail:
|
|
|
|
view_tail
|
|
|
|
{}
|
|
|
|
| trigger_tail
|
|
|
|
{}
|
|
|
|
| sp_tail
|
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
|
|
|
/**************************************************************************
|
|
|
|
|
|
|
|
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_algorithm_opt:
|
|
|
|
/* empty */
|
|
|
|
{ Lex->create_view_algorithm= VIEW_ALGORITHM_UNDEFINED; }
|
|
|
|
| view_algorithm
|
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
view_list_opt AS view_select view_check_option
|
|
|
|
{}
|
|
|
|
;
|
|
|
|
|
|
|
|
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
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
view_select_aux
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
;
|
|
|
|
|
|
|
|
view_select_aux:
|
2005-11-10 20:25:03 +01:00
|
|
|
SELECT_SYM remember_name select_init2
|
|
|
|
{
|
2005-12-02 20:18:12 +01:00
|
|
|
THD *thd=YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
char *stmt_beg= (lex->sphead ?
|
|
|
|
(char *)lex->sphead->m_tmp_query :
|
|
|
|
thd->query);
|
|
|
|
lex->create_view_select_start= $2 - stmt_beg;
|
2005-11-10 20:25:03 +01:00
|
|
|
}
|
|
|
|
| '(' remember_name select_paren ')' union_opt
|
|
|
|
{
|
2005-12-02 20:18:12 +01:00
|
|
|
THD *thd=YYTHD;
|
|
|
|
LEX *lex= thd->lex;
|
|
|
|
char *stmt_beg= (lex->sphead ?
|
|
|
|
(char *)lex->sphead->m_tmp_query :
|
|
|
|
thd->query);
|
|
|
|
lex->create_view_select_start= $2 - stmt_beg;
|
2005-11-10 20:25:03 +01:00
|
|
|
}
|
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:
|
2006-02-24 21:50:36 +01:00
|
|
|
TRIGGER_SYM remember_name sp_name trg_action_time trg_event
|
2006-03-04 14:55:06 +01:00
|
|
|
ON remember_name table_ident FOR_SYM remember_name EACH_SYM ROW_SYM
|
2005-11-10 20:25:03 +01:00
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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;
|
|
|
|
|
|
|
|
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
|
|
|
}
|
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;
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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;
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
sp->init_sp_name(thd, $3);
|
2005-11-10 20:25:03 +01:00
|
|
|
|
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;
|
2006-03-04 14:55:06 +01:00
|
|
|
lex->ident.length= $10 - $7;
|
2006-02-24 21:50:36 +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 ';'.
|
|
|
|
*/
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
sp->m_old_cmq= thd->client_capabilities & CLIENT_MULTI_QUERIES;
|
|
|
|
thd->client_capabilities &= ~CLIENT_MULTI_QUERIES;
|
2005-11-10 20:25:03 +01:00
|
|
|
|
|
|
|
bzero((char *)&lex->sp_chistics, sizeof(st_sp_chistics));
|
|
|
|
lex->sphead->m_chistics= &lex->sp_chistics;
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
lex->sphead->m_body_begin= lip->ptr;
|
2006-01-12 01:02:52 +01:00
|
|
|
while (my_isspace(system_charset_info, lex->sphead->m_body_begin[0]))
|
|
|
|
++lex->sphead->m_body_begin;
|
2005-11-10 20:25:03 +01:00
|
|
|
}
|
|
|
|
sp_proc_stmt
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
|
|
|
|
lex->sql_command= SQLCOM_CREATE_TRIGGER;
|
2006-07-27 15:57:43 +02:00
|
|
|
sp->init_strings(YYTHD, lex);
|
2005-11-10 20:25:03 +01:00
|
|
|
/* Restore flag if it was cleared above */
|
|
|
|
if (sp->m_old_cmq)
|
|
|
|
YYTHD->client_capabilities |= CLIENT_MULTI_QUERIES;
|
|
|
|
sp->restore_thd_mem_root(YYTHD);
|
|
|
|
|
|
|
|
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;
|
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.
|
|
|
|
*/
|
2006-02-24 21:50:36 +01:00
|
|
|
if (!lex->select_lex.add_table_to_list(YYTHD, $8,
|
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 ';'.
|
|
|
|
*/
|
|
|
|
sp->m_old_cmq= YYTHD->client_capabilities & CLIENT_MULTI_QUERIES;
|
|
|
|
YYTHD->client_capabilities &= (~CLIENT_MULTI_QUERIES);
|
|
|
|
}
|
|
|
|
'('
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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 I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
lex->sphead->m_param_begin= lip->tok_start+1;
|
2006-03-02 13:18:49 +01:00
|
|
|
}
|
|
|
|
sp_pdparam_list
|
|
|
|
')'
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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 I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
lex->sphead->m_param_end= lip->tok_start;
|
2006-03-02 13:18:49 +01:00
|
|
|
bzero((char *)&lex->sp_chistics, sizeof(st_sp_chistics));
|
|
|
|
}
|
|
|
|
sp_c_chistics
|
|
|
|
{
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +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;
|
Bug#25411 (trigger code truncated), PART I
The issue found with bug 25411 is due to the function skip_rear_comments()
which damages the source code while implementing a work around.
The root cause of the problem is in the lexical analyser, which does not
process special comments properly.
For special comments like :
[1] aaa /*!50000 bbb */ ccc
since 5.0 is a version older that the current code, the parser is in lining
the content of the special comment, so that the query to process is
[2] aaa bbb ccc
However, the text of the query captured when processing a stored procedure,
stored function or trigger (or event in 5.1), can be after rebuilding it:
[3] aaa bbb */ ccc
which is wrong.
To fix bug 25411 properly, the lexical analyser needs to return [2] when
in lining special comments.
In order to implement this, some preliminary cleanup is required in the code,
which is implemented by this patch.
Before this change, the structure named LEX (or st_lex) contains attributes
that belong to lexical analysis, as well as attributes that represents the
abstract syntax tree (AST) of a statement.
Creating a new LEX structure for each statements (which makes sense for the
AST part) also re-initialized the lexical analysis phase each time, which
is conceptually wrong.
With this patch, the previous st_lex structure has been split in two:
- st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
has not been changed to avoid a bigger impact in the code base.
- class lex_input_stream represents the internal state of the lexical
analyser, which by definition should *not* be reinitialized when parsing
multiple statements from the same input stream.
This change is a pre-requisite for bug 25411, since the implementation of
lex_input_stream will later improve to deal properly with special comments,
and this processing can not be done with the current implementation of
sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
This change set alone does not fix bug 25411.
2007-04-24 17:24:21 +02:00
|
|
|
lex->sphead->m_body_begin= lip->tok_start;
|
2006-03-02 13:18:49 +01:00
|
|
|
}
|
|
|
|
sp_proc_stmt
|
|
|
|
{
|
|
|
|
LEX *lex= Lex;
|
|
|
|
sp_head *sp= lex->sphead;
|
|
|
|
|
2006-07-27 15:57:43 +02:00
|
|
|
sp->init_strings(YYTHD, lex);
|
2006-03-02 13:18:49 +01:00
|
|
|
lex->sql_command= SQLCOM_CREATE_PROCEDURE;
|
|
|
|
/* Restore flag if it was cleared above */
|
|
|
|
if (sp->m_old_cmq)
|
|
|
|
YYTHD->client_capabilities |= CLIENT_MULTI_QUERIES;
|
|
|
|
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; }
|
|
|
|
;
|
|
|
|
|
|
|
|
|