Commit graph

2415 commits

Author SHA1 Message Date
gkodinov/kgeorge@macbook.gmz
06dd1244c3 Bug #23556: TRUNCATE TABLE still maps to DELETE
- TRUNCATE requires DROP privilege, not DELETE
2006-11-21 10:25:10 +02: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
holyfoot/hf@deer.(none)
989117071a Merge mysql.com:/home/hf/work/mysql-5.0-0mrg
into  mysql.com:/home/hf/work/mysql-5.1-mrg
2006-11-19 22:26:36 +04:00
tnurnberg@salvation.intern.azundris.com
655056d32f Bug#16456 RBR: rpl_sp.test expects query to fail, but passes in RBR
Fix tests for new behaviour: an error is thrown if a NON DETERMINISTIC
stored function (SF) is called during statement-based replication (SBR).
2006-11-17 21:30:28 +01: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
jani@ua141d10.elisa.omakaista.fi
596f64d91a Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-5.1-marvel
into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.1-lex-string
2006-11-16 14:38:45 +02:00
tnurnberg@salvation.intern.azundris.com
95fabc6522 Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.1-maint
into  salvation.intern.azundris.com:/home/tnurnberg/work/mysql-5.1-maint-16456
2006-11-15 15:47:29 +01:00
tnurnberg@salvation.intern.azundris.com
c5c46ca483 Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.1-maint
into  salvation.intern.azundris.com:/home/tnurnberg/work/mysql-5.1-maint-16456
2006-11-15 01:58:11 +01:00
tnurnberg@salvation.intern.azundris.com
ea3bf1b247 Bug#16456 "RBR: rpl_sp.test expects query to fail, but passes in RBR"
calling (rather than defining) non-deterministic SP in SBR (as opposed
to RBR or mixed) will throw an error now.

require mixed mode for tests now. SBR will now fail when calling
non-deter SPs and SFs (as it should), and RBR already failed by virtue of
giving different results for "show binlog" than the results-file has.
also test for 16456 now. lastly make amends because one of the tests
fails with a new error # now as code was added to sql_trigger.cc while
test was disabled.
2006-11-15 01:27:39 +01:00
andrey@example.com
d1e5cfd66f Merge ahristov@bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into  example.com:/work/bug23760/my50
2006-11-14 20:48:48 +01:00
andrey@example.com
d57ceecb77 Merge example.com:/work/bug23760/my50
into  example.com:/work/bug23760/my51
2006-11-14 19:10:29 +01:00
andrey@example.com
9299fd6715 Fix for bug#23760 ROW_COUNT() and store procedure not owrking together
The problem was that THD::row_count_func was zeroed too. It was zeroed
as a fix for bug 4905 "Stored procedure doesn't clear for "Rows affected"
However, the proper solution is not to zero, because THD::row_count_func has
been set to -1 already in mysql_execute_command(), a later fix, which obsoletes
the incorrect fix of #4095
2006-11-14 18:40:11 +01:00
evgen@moonbone.local
5198354584 Bug#20045: Server crash on INSERT ... SELECT ... FROM non-mergeable view
The regression is caused by the fix for bug 14767. When INSERT ... SELECT
used a view in the SELECT list that was not inlined, and there was an 
active transaction, the server could crash in Query_cache::invalidate.

On INSERT ... SELECT only the table being inserted into is invalidated.
Thus views that can't be inlined are skipped from invalidation.

The bug manifests itself in two ways so there is 2 test cases.
One checks that the only the table being inserted into is invalidated.
And the second one checks that there is no crash on INSERT ... SELECT.
2006-11-14 19:50:44 +03:00
lars@black.(none)
63c906f749 Merge mysql.com:/home/bkroot/mysql-5.1-new-rpl
into  mysql.com:/home/bk/MERGE/mysql-5.1-merge
2006-11-13 12:45:31 +01:00
lars/lthalmann@dl145h.mysql.com
3776e9622b Merge mysql.com:/users/lthalmann/bkroot/mysql-5.1-new-rpl
into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.1-merge
2006-11-07 19:26:31 +01:00
anozdrin/alik@alik.
ee15c11b7c Merge alik.:/mnt/raid/alik/MySQL/devel/5.1
into  alik.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged-2
2006-11-07 16:24:35 +03:00
lars/lthalmann@mysql.com/dl145h.mysql.com
aea1e14ef8 Merge mysql.com:/users/lthalmann/bkroot/mysql-5.0-rpl
into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
2006-11-07 12:02:53 +01:00
anozdrin/alik@alik.
18fb4abff4 Merge alik.:/mnt/raid/alik/MySQL/devel/5.1-monty
into  alik.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged
2006-11-03 14:00:35 +03:00
bar@bar.intranet.mysql.r18.ru
8803496903 Merge mysql.com:/usr/home/bar/mysql-5.0-rpl
into  mysql.com:/usr/home/bar/mysql-5.1-rpl
2006-11-03 10:29:44 +04:00
cmiller@zippy.cornsilk.net
b074e13483 Merge bk-internal.mysql.com:/home/bk/mysql-5.1
into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-maint
2006-11-02 17:51:59 -05:00
cmiller@zippy.cornsilk.net
af5acac047 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint
2006-11-02 17:39:52 -05:00
andrey@example.com
63f7ca0662 Merge ahristov@bk-internal.mysql.com:/home/bk/mysql-5.1-runtime
into  example.com:/work/mysql-5.1-runtime-bug22830-new
2006-11-02 13:59:44 +01:00
andrey@example.com
c27a88ca2d Better fix for bug#22830
Events: crash with procedure which alters events with function

Post-review CS

This fix also changes the handling of KILL command combined with
subquery. It changes the error message given back to "not supported",
from parse error. The error for CREATE|ALTER EVENT has also been changed
to generate "not supported yet" instead of parse error.
In case of a SP call, the error is "not supported yet". This change
cleans the parser from code which should not belong to there. Still
LEX::expr_allows_subselect is existant because it simplifies the handling
 of SQLCOM_HA_READ which forbids subselects.
2006-11-02 13:51:43 +01:00
kostja@bodhi.local
aaeef40e72 Merge bodhi.local:/opt/local/work/mysql-5.0-runtime
into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge
2006-11-02 03:30:16 +03:00
monty@mysql.com/nosik.monty.fi
ca99516cc7 Fixed a lot of compiler warnings (Mainly in mysqld and instance manager)
Fixed some possible fatal wrong arguments to printf() style functions
Initialized some not initialized variables
Fixed bug in stored procedure and continue handlers
(Fixes Bug#22150)
2006-11-01 19:41:09 +02:00
bar@mysql.com/bar.intranet.mysql.r18.ru
c378d3a1ec Merge abarkov@bk-internal.mysql.com:/home/bk/mysql-5.0-rpl
into  mysql.com:/usr/home/bar/mysql-5.0.b22877
2006-11-01 12:34:42 +04:00
bar@mysql.com/bar.intranet.mysql.r18.ru
ac9e3db9a7 Bug#22877 replication character sets get out of
sync using replicate-wild-ignore-table
Problem: changes in character set variables
before an action on an replication-ignored table
makes slave to forget new variable values.
Fix: initialize one_shot variables only when
4.1 -> 5.x replication is running.
2006-11-01 12:30:01 +04:00
bar@mysql.com/bar.intranet.mysql.r18.ru
d18fcb3a0f Bug#20404: SHOW CREATE TABLE fails with Turkish I
Problem: SHOW CREATE TABLE printed garbage in table
  name for tables having TURKISH I
  (i.e. LATIN CAPITABLE LETTER I WITH DOT ABOVE)
  when lower-case-table-name=1.
  
  Reason: In some cases during lower/upper conversion in utf8,
  the result string can be shorter the original string
  (including the above letter). Old implementation of caseup_str()
  and casedn_str() didn't handle the result length properly,
  assuming that length cannot change.
  
  This fix changes the result type of cs->cset->casedn_str()
  and cs->cset->caseup_str() from VOID to UINT, to return
  the result length, as well as put '\0' terminator on a 
  proper place.
  
  Also, my_caseup_str_utf8() and my_casedn_str_utf8() were 
  rewritten not to use strlen() for performance purposes.
  It was done with help of adding of new functions - my_utf8_uni_no_range()
  and my_uni_utf8_no_range() - for null terminated strings.
2006-10-30 14:40:15 +04:00
kostja@bodhi.local
dfc4dd423c A cleanup. 2006-10-30 12:03:42 +03:00
kroki/tomash@moonlight.intranet
db952c2faa Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug22584
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug22584
2006-10-27 13:40:28 +04:00
kroki/tomash@moonlight.intranet
0e0f7a0423 BUG#22584: last_insert_id not updated after inserting a record through
a updatable view.

When there's a VIEW on a base table that have AUTO_INCREMENT column, and
this VIEW doesn't provide an access such column, after INSERT to such
VIEW LAST_INSERT_ID() did not return the value just generated.

This behaviour is intended and correct, because if the VIEW doesn't list
some columns then these columns are effectively hidden from the user,
and so any side effects of inserting default values to them.

However, there was a bug that such statement inserting into a view would
reset LAST_INSERT_ID() instead of leaving it unchanged.

This patch restores the original value of LAST_INSERT_ID() instead of
resetting it to zero.
2006-10-27 13:32:41 +04:00
ramil/ram@myoffice.izhnet.ru
9f1a271c70 Merge mysql.com:/usr/home/ram/work/bug22158/my50-bug22158
into  mysql.com:/usr/home/ram/work/bug22158/my51-bug22158
2006-10-27 08:59:56 +05:00
ramil/ram@mysql.com/myoffice.izhnet.ru
7b90a45425 Fix for bug #22158: Errors in init_connect terminate connections silently
When executing the init_connect statement, thd->net.vio is set to 0, to         
forbid sending any results to the client. As a side effect we don't log         
possible errors, either.                                                        
                                                                                
Now we write warnings to the error log if an init_connect query                
fails.
2006-10-26 14:51:34 +05:00
kroki/tomash@moonlight.intranet
dea0028cd9 Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21856
2006-10-19 14:53:50 +04:00
kroki/tomash@moonlight.intranet
2a857d2fb3 Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21856
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug21856
2006-10-19 14:49:16 +04:00
kroki/tomash@moonlight.intranet
00b2fc6aff BUG#21856: Prepared Statements: crash if bad create
When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION
or CREATE TRIGGER statements with a syntax error in it, the preparation
would fail with syntax error message, but the memory could be corrupted.

The problem occurred because we switch memroot when parse stored
routine or trigger definitions, and on parse error we restored the
original memroot only after performing some memory operations.  In more
detail:
 - prepared statement would activate its own memory root to parse
   the definition of the stored procedure.
 - SP would reset this memory root with its own memory root to
   parse SP statements
 - a syntax error would happen
 - prepared statement would restore the original memory root
 - stored procedure would restore what it thinks was the original
   memory root, but actually was the statement memory root.
That led to double free - in destruction of the statement and in
a next call to mysql_parse().

The solution is to restore memroot right after the failed parsing.
2006-10-19 14:43:52 +04:00
jani@ua141d10.elisa.omakaista.fi
8dd0b2d0ae Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-5.1
into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.1-lex-string
2006-10-17 19:54:44 +03:00
cmiller@zippy.cornsilk.net
7714fea9a2 Merge zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint
into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint_20061016
2006-10-17 12:31:52 -04:00
cmiller@zippy.cornsilk.net
91c4edfbfb Merge zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint_20061016
into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-maint
2006-10-17 12:00:36 -04:00
cmiller@zippy.cornsilk.net
3a709f50b2 Fix previous bad patch for Bug#14262.
Remove table engine qualification where it's unnecessary.
2006-10-17 11:06:11 -04:00
tsmith/tim@siva.hindu.god
df200bd018 Merge siva.hindu.god:/usr/home/tim/m/bk/b19764/50
into  siva.hindu.god:/usr/home/tim/m/bk/tmp/mrgOct16/50
2006-10-16 20:15:14 -06:00
jani@ua141d10.elisa.omakaista.fi
02f29377fd Changed several char* to LEX_STRING*. 2006-10-16 19:57:33 +03:00
cmiller@zippy.cornsilk.net
87ba07e832 Merge bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into  zippy.cornsilk.net:/home/cmiller/work/mysql/bug14262/my50-bug14262
2006-10-13 08:57:15 -04:00
tsmith/tim@siva.hindu.god
0e3cfe02ec Bug #19764: SHOW commands end up in the slow log as table scans
Do not consider SHOW commands slow queries, just because they don't use proper indexes.

This bug fix is not needed in 5.1, and the code changes will be null merged.  However, the test cases will be propogated up to 5.1.
2006-10-12 17:10:34 -06:00
tsmith/tim@siva.hindu.god
360540e891 Revert patch for bug #19764, which did not work with prepared statements. 2006-10-11 23:35:52 -06:00
cmiller@zippy.cornsilk.net
1279acd975 Merge zippy.cornsilk.net:/home/cmiller/work/mysql/bug14262/my50-bug14262
into  zippy.cornsilk.net:/home/cmiller/work/mysql/bug14262/my51
2006-10-11 16:49:59 -04:00
kroki/tomash@moonlight.intranet
ee0cebf9a7 BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID.
Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored
procedures.  However, 4.1 had some bugs that were fixed in 5.0 by the
patch for bug#21726, and this patch is a backport of those fixes.
Namely, in 4.1 it fixes:

  - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific).

  - LAST_INSERT_ID() could return the value generated by current
    statement if the call happens after the generation, like in

      CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT);
      INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID());

  - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
2006-10-06 13:34:07 +04:00
tsmith/tim@siva.hindu.god
f5c4d75e8f Bug #19764: SHOW commands end up in the slow log as table scans
Set a flag when a SHOW command is parsed, and check it in log_slow_statement().  SHOW commands are not counted as slow queries, even if they use table scans.
2006-10-03 21:26:55 -06:00