Commit graph

9770 commits

Author SHA1 Message Date
thek@kpdesk.mysql.com
294cb8432f Bug#22043 MySQL don't add "USE <DATABASE>" before "DROP PROCEDURE EXISTS"
- CREATE PROCEDURE stores database name based on query context instead
  of 'current database' as set by 'USE' according to manual.
  The bug reporter interpret the filtering statements as bug for
   DROP PROCEDURE based on this behavior.
- Removed the code which changes db context.
- Added code to check that a valid db was supplied.
2006-11-28 16:03:53 +01:00
gkodinov/kgeorge@rakia.gmz
fb41ec6f22 Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  rakia.gmz:/home/kgeorge/mysql/autopush/B11927-5.0-opt
2006-11-28 15:47:53 +02:00
gkodinov/kgeorge@macbook.gmz
42cd956752 BUG#11927: Warnings shown for CAST( chr as signed) but not (chr + 0)
When implicitly converting string fields to numbers the 
 string-to-number conversion error was not sent to the client.
 Added code to send the conversion error as warning.
 
 We also need to prevent generation of warnings from the places
 where val_xxx() methods are called for the sole purpose of updating
 the Item::null_value flag.
 To achieve that a special function is added (and called) : 
 update_null_value(). This function will set the no_errors flag and
 will call val_xxx(). The warning generation in Field_string::val_xxx()
 will use the flag when generating the conversion warnings.
2006-11-28 15:44:11 +02:00
bar@mysql.com/bar.intranet.mysql.r18.ru
a70028a855 Bug#20396 Bin Log does not get DELIMETER cmd - Recover StoredProc fails
Problem: when loading mysqlbinlog dumps, CREATE PROCEDURE having semicolons
in their bodies failed.
Fix: Using safe delimiter "/*!*/;" to dump log entries.
2006-11-28 16:26:15 +04:00
msvensson@neptunus.(none)
8a0761201a Merge bk-internal:/home/bk/mysql-5.0-maint
into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
2006-11-28 11:50:48 +01:00
monty@mysql.com/nosik.monty.fi
9c3a2a0d8e Increased heap max length to > 4G for 64 bit machines
Initialize key_part->type on open. This caused key_copy() to fail for bit_fields. (key_copy is used in HANDLER and opt_range)
2006-11-28 00:47:21 +02:00
jpipes@shakedown.(none)
03a5dcd7ce Merge bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into  shakedown.(none):/home/jpipes/dev/mysql-5.0-maint
2006-11-27 14:58:57 -05:00
msvensson@neptunus.(none)
76b8b450d6 Fix for rpl000015 that fails if $MYSQL_TCP_PORT is set. The default value for
master_port after a "change master" will be set to the compiled in default value
i.e not always the same as what the master report as it's port number.
2006-11-27 19:56:04 +01:00
kaa@polly.local
32d1ad79b0 Fix for bug #24261 "crash when WHERE contains NOT IN ('<negative value>') for unsigned column type"
When calculating a SEL_TREE for the "c_{i-1} < X < c_i" interval, check if the tree returned for the "-inf < X < c_0" interval is NULL
2006-11-27 19:12:10 +03:00
gkodinov@dl145s.mysql.com
e74c9add47 Merge bk-internal:/home/bk/mysql-5.0
into  dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE/mysql-5.0-opt
2006-11-27 16:25:52 +01:00
evgen@moonbone.local
b5b7b03ff3 Bug#17254: Error for DEFINER security on VIEW provides too much info
If a view was created with the DEFINER security and later the definer user
was dropped then a SELECT from the view throws the error message saying that
there is no definer user is registered. This is ok for a root but too much
for a mere user.

Now the st_table_list::prepare_view_securety_context() function reveals
the absence of the definer only to a superuser and throws the 'access denied'
error to others.
2006-11-27 16:15:32 +03:00
kaa@polly.local
699898c82c Merge polly.local:/tmp/maint/bug22077/my50-bug22077
into  polly.local:/home/kaa/src/maint/mysql-5.0-maint
2006-11-24 17:01:43 +03:00
msvensson@neptunus.(none)
86f0d1bb03 Merge neptunus.(none):/home/msvensson/mysql/mysql-4.1
into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint
2006-11-24 12:12:25 +01:00
anozdrin/alik@booka.
ea47e05f3c Fix for BUG##24415: Instance manager test im_daemon_life_cycle
fails randomly.

The problem was that the test case used command line tool (mysql)
without specifying connect_timeout argument. In some cases,
this lead to hanging of the test case.

The fix is to specify --connect_timeout=1 when starting mysql.

Also, the patch contains polishing and various cleanups to simplify
analyzing of the problems further.

The patch affects only test suite, no server codebase has been
touched.
2006-11-23 22:55:36 +03:00
monty@mysql.com/nosik.monty.fi
501333f694 Added option --mtr-build-thread to mysql-test-run.pl
Load shared libraries from zlib (fixed that mysql-test-run.pl didn't work on some Solaris boxes)
Added connect timeout to test to make im_daemon_life_cycle more predictable
2006-11-23 18:39:10 +02:00
ramil/ram@mysql.com/myoffice.izhnet.ru
711b6a63be Merge rkalimullin@bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into  mysql.com:/usr/home/ram/work/bug22029/my50-bug22029
2006-11-22 10:52:44 +04:00
ramil/ram@mysql.com/myoffice.izhnet.ru
c6e856de10 Merge rkalimullin@bk-internal.mysql.com:/home/bk/mysql-4.1-maint
into  mysql.com:/usr/home/ram/work/bug22029/my41-bug22029
2006-11-22 10:30:46 +04:00
ramil/ram@mysql.com/myoffice.izhnet.ru
b1a423d9f6 Merge rkalimullin@bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into  mysql.com:/usr/home/ram/work/bug22029/my50-bug22029
2006-11-22 10:27:11 +04:00
iggy@rolltop.ignatz42.dyndns.org
e2a6759c4a Bug#19799 delimiter command not working correctly when sourcing a sql file
- Use more appropriate test case.
2006-11-22 01:27:06 -05:00
ramil/ram@mysql.com/myoffice.izhnet.ru
0a415e360c Merge mysql.com:/usr/home/ram/work/bug22029/my41-bug22029
into  mysql.com:/usr/home/ram/work/bug22029/my50-bug22029
2006-11-22 09:19:51 +04:00
iggy@rolltop.ignatz42.dyndns.org
bface97ecc Bug#19799 delimiter command not working correctly when sourcing a sql file
- Client side readline functions unconditionally search for Unix '\n' line
endings. In this case, the delimiter statement was set to '//\r' instead 
of the intended '//'. When removing the '\n' check for and remove 
preceeding '\r' character as well.
2006-11-21 21:10:02 -05:00
kroki/tomash@moonlight.intranet
7cde1656e4 Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug23159
2006-11-21 17:37:57 +03:00
kroki/tomash@moonlight.intranet
0a36a6f382 Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-runtime
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug23159
2006-11-21 17:37:25 +03:00
msvensson@neptunus.(none)
7cf226de11 Rename system_mysql_db_fix.test to system_mysql_db_fix30020 as it tests
mysql_fix_privilege_tables.s's ability to convert the system tables as of
3.20 to current system table format
Add similar test for 4.1.23 tables - but use "mysql < mysql_fix_privilege_tables.sql"
so it can be run on any platform.
2006-11-21 15:31:11 +01:00
kroki/tomash@moonlight.intranet
cb69318963 Fix after manual merge. 2006-11-21 16:57:23 +03:00
kroki/tomash@moonlight.intranet
2bde57836c Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug23159
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug23159
2006-11-21 16:53:33 +03:00
kroki/tomash@moonlight.intranet
0d588f8882 BUG#23159: prepared_stmt_count should be status variable
Make Prepared_stmt_count a global status variable, accessible via
SHOW STATUS LIKE 'Prepared_stmt_count';.  Documentation should be
updated.
2006-11-21 16:49:18 +03:00
gluh@mysql.com/gluh.(none)
ff38409128 Bug#22413 EXPLAIN SELECT FROM view with ORDER BY yield server crash
disable filling of I_S tables for EXPLAIN
2006-11-21 13:45:01 +04:00
bar@mysql.com/bar.intranet.mysql.r18.ru
78c74b0396 Prepare to merge "backport of bug#13926 from 5.0 to 4.1" back into 5.0:
Moving tests into their new place into 4.1 tests section
2006-11-21 12:09:14 +04:00
bar@mysql.com/bar.intranet.mysql.r18.ru
fb419c4241 BUG#13926: --order-by-primary fails if PKEY contains quote character.
Backporting from 5.0
2006-11-21 11:09:33 +04:00
monty@mysql.com/nosik.monty.fi
306b871d52 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  mysql.com:/home/my/mysql-5.0
2006-11-20 22:46:52 +02:00
monty@mysql.com/nosik.monty.fi
e825879800 Remove compiler warnings
(Mostly in DBUG_PRINT() and unused arguments)
Fixed bug in query cache when used with traceing (--with-debug)
Fixed memory leak in mysqldump
Removed warnings from mysqltest scripts (replaced -- with #)
2006-11-20 22:42:06 +02:00
kaa@polly.local
346033a5da Fix for bug #22077 "DROP TEMPORARY TABLE fails with wrong error if read_only is set"
Do not issue a 'read-only' error in case of DROP TEMPORARY TABLE on a non-existing temporary table.
Instead produce the correct "Unknown table" error or warning (in cases when the IF EXISTS clause was specified).

To a documentor: the part of the manual describing the 'read_only' system variable should be clarified to state the following:
"When the read_only variable is set to ON, all operations which create/update/drop tables are rejected with the exceptions for:
1. Any operation performed by the replication thread on a slave server
2. Any operation performed by a user that have the SUPER privilege
3. Any operation that creates/updates/drops only temporary tables"
2006-11-20 17:35:23 +03:00
bar@mysql.com/bar.intranet.mysql.r18.ru
a363599a81 Merge mysql.com:/usr/home/bar/mysql-4.1.b22646
into  mysql.com:/usr/home/bar/mysql-4.1-rpl
2006-11-20 18:08:46 +04:00
bar@mysql.com/bar.intranet.mysql.r18.ru
6f6868bfe2 Merge mysql.com:/usr/home/bar/mysql-4.1.b22646
into  mysql.com:/usr/home/bar/mysql-5.0.b22646
2006-11-20 15:06:33 +04:00
malff/marcsql@weblab.(none)
ce5a3fcca8 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 12:14:29 -07:00
holyfoot/hf@mysql.com/deer.(none)
e95e23b0f3 Merge bk@192.168.21.1:mysql-5.0-opt
into  mysql.com:/home/hf/work/mysql-5.0-0mrg
2006-11-17 10:30:16 +04:00
holyfoot/hf@mysql.com/deer.(none)
497ccd6b87 Merge mysql.com:/home/hf/work/mysql-4.1-mrg
into  mysql.com:/home/hf/work/mysql-5.0-mrg
2006-11-16 23:16:44 +04:00
holyfoot/hf@mysql.com/deer.(none)
db5db841a9 Merge bk@192.168.21.1:mysql-4.1
into  mysql.com:/home/hf/work/mysql-4.1-mrg
2006-11-16 20:44:37 +04:00
andrey@example.com
8b947e265b Merge ahristov@bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into  example.com:/work/bug24219/my50
2006-11-16 16:37:07 +01:00
andrey@example.com
2e13117808 Merge ahristov@bk-internal.mysql.com:/home/bk/mysql-4.1-maint
into  example.com:/work/bug24219/my41
2006-11-16 16:29:06 +01:00
andrey@example.com
e5035f9020 Merge example.com:/work/bug24219/my41
into  example.com:/work/bug24219/my50
2006-11-16 13:46:43 +01:00
andrey@example.com
de904f54bf Fix for bug#24219 ALTER TABLE ... RENAME TO ... , DISABLE KEYS leads to crash
There was an improper order of doing chained operations.

To the documentor: ENABLE|DISABLE KEYS combined with RENAME TO, and no other
ALTER TABLE clause, leads to server crash independent of the presence of
indices and data in the table.
2006-11-16 13:18:37 +01:00
ramil/ram@mysql.com/myoffice.izhnet.ru
1bd5c0d51d Merge rkalimullin@bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into  mysql.com:/usr/home/ram/work/bug23653/my50-bug23653
2006-11-16 16:17:29 +04:00
ramil/ram@mysql.com/myoffice.izhnet.ru
b4dd41de69 Merge mysql.com:/usr/home/ram/work/bug23653/my41-bug23653
into  mysql.com:/usr/home/ram/work/bug23653/my50-bug23653
2006-11-16 15:26:33 +04:00
kroki/tomash@moonlight.intranet
2b9bcb2c3c Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug17047
2006-11-16 14:19:37 +03:00
kroki/tomash@moonlight.intranet
690cb27d05 Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-runtime
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug17047
2006-11-16 14:15:56 +03:00
kroki/tomash@moonlight.intranet
9e7f682116 Add 5.0 part of fix for bug 17047. 2006-11-16 14:06:51 +03:00
kroki/tomash@moonlight.intranet
23efecdb3c Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug17047
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug17047
2006-11-16 13:25:55 +03:00
kroki/tomash@moonlight.intranet
b8d5451565 BUG#17047: CHAR() and IN() can return NULL without signaling NULL result
The problem was that some functions (namely IN() starting with 4.1, and
CHAR() starting with 5.0) were returning NULL in certain conditions,
while they didn't set their maybe_null flag.  Because of that there could
be some problems with 'IS NULL' check, and statements that depend on the
function value domain, like CREATE TABLE t1 SELECT 1 IN (2, NULL);.

The fix is to set maybe_null correctly.
2006-11-16 13:21:38 +03:00