Commit graph

801 commits

Author SHA1 Message Date
tsmith@maint2.mysql.com
e2f40aa6d0 Merge maint2.mysql.com:/data/localhome/tsmith/bk/41
into  maint2.mysql.com:/data/localhome/tsmith/bk/50
2006-09-01 08:53:56 +02:00
ramil/ram@mysql.com/myoffice.izhnet.ru
6660f98b64 Fix for bug #20695: Charset introducer overrides charset definition for column.
- if there are two character set definitions in the column declaration,
    we replace the first one with the second one as we store both in the LEX->charset
    slot. Add a separate slot to the LEX structure to store underscore charset.
  - convert default values to the column charset of STRING, VARSTRING fields 
    if necessary as well.
2006-08-15 15:24:07 +05:00
anozdrin/alik@booka.
b7f403b546 Fix for BUG#16211: Stored function return type for strings is ignored.
Fix for BUG#16676: Database CHARSET not used for stored procedures

The problem in BUG#16211 is that CHARSET-clause of the return type for
stored functions is just ignored.

The problem in BUG#16676 is that if character set is not explicitly
specified for sp-variable, the server character set is used instead
of the database one.

The fix has two parts:

  - always store CHARSET-clause of the return type along with the
    type definition in mysql.proc.returns column. "Always" means that
    CHARSET-clause is appended even if it has not been explicitly
    specified in CREATE FUNCTION statement (this affects BUG#16211 only).

    Storing CHARSET-clause if it is not specified is essential to avoid
    changing character set if the database character set is altered in
    the future.

    NOTE: this change is not backward compatible with the previous releases.

  - use database default character set if CHARSET-clause is not explicitly
    specified (this affects both BUG#16211 and BUG#16676).

    NOTE: this also breaks backward compatibility.
2006-07-27 17:57:43 +04:00
kostja@bodhi.local
fbf54f8d72 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41
2006-07-11 17:04:27 +04:00
ingo/mydev@chilla.local
50b630ba7c Merge chilla.local:/home/mydev/mysql-5.0-release
into  chilla.local:/home/mydev/mysql-5.0-amerge
2006-07-11 13:01:27 +02:00
ingo/mydev@chilla.local
dfaa3c78f6 Revoking patch for Bug#10952 on behalf of Brian. 2006-07-10 20:46:05 +02:00
kostja@bodhi.local
7bf73ac3e5 Merge bodhi.local:/opt/local/work/mysql-5.0-root
into  bodhi.local:/opt/local/work/mysql-5.0-runtime
2006-07-07 22:09:43 +04:00
dlenev@mysql.com
b429748fab Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  mysql.com:/home/dlenev/mysql-5.0-bg18437-3
2006-07-06 14:31:32 +04:00
dlenev@mysql.com
d4450e6696 Fix for bug#18437 "Wrong values inserted with a before update trigger on
NDB table".

SQL-layer was not marking fields which were used in triggers as such. As
result these fields were not always properly retrieved/stored by handler
layer. So one might got wrong values or lost changes in triggers for NDB,
Federated and possibly InnoDB tables.
This fix solves the problem by marking fields used in triggers
appropriately.

Also this patch contains the following cleanup of ha_ndbcluster code:

We no longer rely on reading LEX::sql_command value in handler in order
to determine if we can enable optimization which allows us to handle REPLACE
statement in more efficient way by doing replaces directly in write_row()
method without reporting error to SQL-layer.
Instead we rely on SQL-layer informing us whether this optimization
applicable by calling handler::extra() method with
HA_EXTRA_WRITE_CAN_REPLACE flag.
As result we no longer apply this optimzation in cases when it should not
be used (e.g. if we have on delete triggers on table) and use in some
additional cases when it is applicable (e.g. for LOAD DATA REPLACE).

Finally this patch includes fix for bug#20728 "REPLACE does not work
correctly for NDB table with PK and unique index".
  
This was yet another problem which was caused by improper field mark-up.
During row replacement fields which weren't explicity used in REPLACE
statement were not marked as fields to be saved (updated) so they have
retained values from old row version. The fix is to mark all table
fields as set for REPLACE statement. Note that in 5.1 we already solve
this problem by notifying handler that it should save values from all
fields only in case when real replacement happens.
2006-07-02 01:51:10 +04:00
gluh@eagle.intranet.mysql.r18.ru
a230166f28 Fix for bug#13934 Silent truncation of table comments
Table comment: issue a warning(error in traditional mode) if length of comment > 60 symbols
Column comment: issue a warning(error in traditional mode) if length of comment > 255 symbols
Table 'comment' is changed from char* to LEX_STRING
2006-06-29 18:39:34 +05:00
konstantin@mysql.com
5576ef27c6 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  mysql.com:/opt/local/work/mysql-5.0-17199
2006-06-27 03:34:12 +04:00
konstantin@mysql.com
4d25d2154c Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  mysql.com:/opt/local/work/mysql-5.0-17199
2006-06-27 00:52:56 +04:00
konstantin@mysql.com
117b76a562 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-27 00:47:52 +04:00
ingo@mysql.com
0acdd0f773 Merge istruewing@bk-internal.mysql.com:/home/bk/mysql-5.0
into  mysql.com:/home/mydev/mysql-5.0-bug16986-main
2006-06-26 19:43:28 +02:00
ingo@mysql.com
d27a15a81c Bug#16986 - Deadlock condition with MyISAM tables
Addendum fixes after changing the condition variable
for the global read lock.

The stress test suite revealed some deadlocks. Some were
related to the new condition variable (COND_global_read_lock)
and some were general problems with the global read lock.

It is now necessary to signal COND_global_read_lock whenever 
COND_refresh is signalled.

We need to wait for the release of a global read lock if one 
is set before every operation that requires a write lock.
But we must not wait if we have locked tables by LOCK TABLES.
After setting a global read lock a thread waits until all
write locks are released.
2006-06-26 19:14:35 +02:00
iggy@mysql.com
f68b01e347 Bug#20616: drop_temp_table test fails on Windows platform 2006-06-23 12:15:39 -04:00
svoj@may.pils.ru
77ab3b28a7 BUG#19192 - CHECK TABLE EXTENDED / REPAIR TABLE show no errors.
ALTER TABLE crashes
Executing fast alter table (one that doesn't need to copy data)
on tables created by mysql versions prior to 4.0.25 could result
in posterior server crash when accessing these tables.

There was a bug prior to mysql-4.0.25. Number of null fields was
calculated incorrectly. As a result frm and data files gets out of
sync after fast alter table. There is no way to determine by which
mysql version (in 4.0 and 4.1 branches) table was created, thus we
disable fast alter table for all tables created by mysql versions
prior to 5.0 branch.
See BUG#6236.
2006-06-01 18:08:57 +05:00
gluh@eagle.intranet.mysql.r18.ru
ae72df07f2 Bug#17204 "second CALL to procedure crashes Server"
Bug#18282 "INFORMATION_SCHEMA.TABLES provides inconsistent info about invalid views"
This bug caused crashes or resulted in wrong data being returned
when one tried to obtain information from I_S tables about views
using stored functions.

It was caused by the fact that we were using LEX representing
statement which were doing select from I_S tables as active LEX
when contents of I_S table were built. So state of this LEX both
affected and was affected by open_tables() calls which happened
during this process. This resulted in wrong behavior and in
violations of some of invariants which caused crashes.

This fix tries to solve this problem by properly saving/resetting
and restoring part of LEX which affects and is affected by the
process of opening tables and views in get_all_tables() routine.
To simplify things we separated this part of LEX in a new class
and made LEX its descendant.
2006-05-30 10:45:23 +05:00
svoj@april.(none)
0674c702b0 Merge svojtovich@bk-internal.mysql.com:/home/bk/mysql-5.0
into  april.(none):/home/svoj/devel/mysql/BUG17001/mysql-5.0
2006-05-24 15:13:49 +05:00
svoj@april.(none)
3afbfc5fed BUG#17001 - Table and server crash on ALTER TABLE
frm and data files for tables created by earlier MySQL
versions becomes out of sync after certain ALTER TABLE statements:
- One that changes column default value;
- One that changes table comment;
- One that changes table password.

As a result one can expirience either server crash or data corruption/loss.

This fix ensures that running ALTER TABLE on tables created by earlier
MySQL versions recreates data files.
2006-05-16 18:37:23 +05:00
konstantin@mysql.com
85c6883146 Merge mysql.com:/opt/local/work/mysql-5.0-root
into  mysql.com:/opt/local/work/mysql-5.0-runtime-merge
2006-05-15 00:51:12 +04:00
acurtis@xiphis.org
7c9b4c2792 Merge acurtis@bk-internal:/home/bk/mysql-5.0-engines
into  xiphis.org:/home/antony/work2/p1-bug10952.1
2006-05-09 13:34:31 -07:00
acurtis@xiphis.org
47e89f208a bug#10952
"alter table from MyISAM to MERGE lost data without errors and warnings"
  Add new handlerton flag which prevent user from altering table storage
  engine to storage engines which would lose data. Both 'blackhole' and 
  'merge' are marked with the new flag.
  Tests included.
2006-05-09 13:31:46 -07:00
dlenev@mysql.com
b9d49ee894 Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  mysql.com:/home/dlenev/mysql-5.0-bg12472
2006-05-09 16:48:23 +04:00
dlenev@mysql.com
589daad10f Fix for bugs#12472/#15137 'CREATE TABLE ... SELECT ... which explicitly
or implicitly uses stored function gives "Table not locked" error'

CREATE TABLE ... SELECT ... statement which was explicitly or implicitly
(through view) using stored function gave "Table not locked" error.

The actual bug resides in the current locking scheme of CREATE TABLE SELECT
code, which first opens and locks tables of the SELECT statement itself,
and then, having SELECT tables locked, creates the .FRM, opens the .FRM and
acquires lock on it. This scheme opens a possibility for a deadlock, which
was present and ignored since version 3.23 or earlier. This scheme also
conflicts with the invariant of the prelocking algorithm -- no table can
be open and locked while there are tables locked in prelocked mode.

The patch makes an exception for this invariant when doing CREATE TABLE ...
SELECT, thus extending the possibility of a deadlock to the prelocked mode.
We can't supply a better fix in 5.0.
2006-05-09 16:39:11 +04:00
holyfoot@mysql.com
2f7ac18f22 Merge bk@192.168.21.1:mysql-5.0
into mysql.com:/home/hf/work/mysql-5.0.mrg
2006-05-04 02:17:17 +05:00
pekka@mysql.com
ec42119233 Merge pnousiainen@bk-internal.mysql.com:/home/bk/mysql-4.1
into  mysql.com:/space/pekka/ndb/version/my50
2006-05-03 23:17:16 +02:00
holyfoot@mysql.com
e5a22d1bca Merge bk@192.168.21.1:mysql-4.1
into mysql.com:/home/hf/work/mysql-4.1.mrg
2006-05-04 00:03:58 +05:00
holyfoot@deer.(none)
81e625ac4a merging fix 2006-05-03 17:43:32 +05:00
holyfoot@mysql.com
7ee205f67a merging 2006-05-03 16:42:39 +05:00
holyfoot@mysql.com
9de68b8122 merging 2006-05-03 16:33:42 +05:00
holyfoot@mysql.com
0007484c26 Merge mysql.com:/home/hf/work/mysql-4.1.15225
into mysql.com:/home/hf/work/mysql-4.1.mrg
2006-05-03 15:51:19 +05:00
ramil@mysql.com
b337e83db2 Merge rkalimullin@bk-internal.mysql.com:/home/bk/mysql-4.1
into  mysql.com:/usr/home/ram/work/4.1.b7643
2006-05-02 11:33:26 +05:00
cmiller@zippy.(none)
6af3f88f07 Merge zippy.(none):/home/cmiller/work/mysql/merge/tmp_merge
into  zippy.(none):/home/cmiller/work/mysql/merge/mysql-5.0
2006-05-01 09:46:00 -04:00
elliot@mysql.com
604b5836bb BUG#19145: mysqld crashes if you set the default value of an enum field to NULL
Now test for NULLness the pointers returned from objects created from the
default value. Pushing patch on behalf of cmiller.
2006-04-28 12:15:29 -04:00
ramil@mysql.com
815da9ccee Fix for bug #7643: ALTER TABLE fails for CSV, EXAMPLE, ARCHIVE engines 2006-04-25 15:27:28 +05:00
holyfoot@deer.(none)
c2acfc5b7c bug #15860 (SPATIAL keys in INNODB) 2006-04-12 22:05:23 +05:00
evgen@sunlight.local
eb075f2255 Manual merge 2006-03-30 17:14:55 +04:00
evgen@sunlight.local
47f9b46564 Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-4.1
into sunlight.local:/local_work/15560-bug-4.1-mysql
2006-03-30 10:22:03 +04:00
gluh@eagle.intranet.mysql.r18.ru
70a8f32d81 post-merge fix 2006-03-30 09:13:25 +05:00
gluh@mysql.com
ea56026e4f Merge 2006-03-30 08:13:28 +05:00
evgen@moonbone.local
1c13e54890 Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
The GROUP_CONCAT uses its own temporary table. When ROLLUP is present
it creates the second copy of Item_func_group_concat. This copy receives the
same list of arguments that original group_concat does. When the copy is
set up the result_fields of functions from the argument list are reset to the
temporary table of this copy.
As a result of this action data from functions flow directly to the ROLLUP copy
and the original group_concat functions shows wrong result.
Since queries with COUNT(DISTINCT ...) use temporary tables to store
the results the COUNT function they are also affected by this bug.

The idea of the fix is to copy content of the result_field for the function
under GROUP_CONCAT/COUNT from  the first temporary table to the second one,
rather than setting result_field to point to the second temporary table.
To achieve this goal force_copy_fields flag is added to Item_func_group_concat
and Item_sum_count_distinct classes. This flag is initialized to 0 and set to 1
into the make_unique() member function of both classes.
To the TMP_TABLE_PARAM structure is modified to include the similar flag as
well.
The create_tmp_table() function passes that flag to create_tmp_field().
When the flag is set the create_tmp_field() function will set result_field
as a source field and will not reset that result field to newly created 
field for Item_func_result_field and its descendants. Due to this there
will be created copy func to copy data from old result_field to newly 
created field.
2006-03-29 23:30:34 +04:00
gluh@eagle.intranet.mysql.r18.ru
2545c7d414 Fix for bug#15316 SET value having comma not correctly handled
disallow the use of comma in SET members
2006-03-29 19:52:26 +05:00
dlenev@mysql.com
4d1d8ed335 Follow-up for the fix for bug #18153 "ALTER/OPTIMIZE/REPAIR on transactional
tables corrupt triggers".

It turned out that we also have relied at certain places that
(new_table != table_name) were always true on Windows and for transactional
tables. Since our fix for the bug brakes this assumption we have to add new
flag to pass this information around.
This code needs to be refactored but I dare not to do this in 5.0.
2006-03-24 22:46:33 +03:00
dlenev@mysql.com
891e9424f2 Fix for bug #18153 "ALTER/OPTIMIZE/REPAIR on transactional tables corrupt
triggers".

Applying ALTER/OPTIMIZE/REPAIR TABLE statements to transactional table or to
table of any type on Windows caused disappearance of its triggers.
Bug was introduced in 5.0.19 by my fix for bug #13525 "Rename table does not
keep info of triggers" (see comment for sql_table.cc for more info).
.
2006-03-24 14:58:18 +03:00
dlenev@mysql.com
6cb5c38c14 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  mysql.com:/home/dlenev/src/mysql-5.0-bg13525
2006-02-27 20:00:03 +03:00
dlenev@mysql.com
4ca3409390 Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  mysql.com:/home/dlenev/src/mysql-5.0-bg13525
2006-02-26 21:20:13 +03:00
dlenev@mysql.com
0b422c635d Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  mysql.com:/home/dlenev/src/mysql-5.0-bg13525
2006-02-26 16:38:48 +03:00
dlenev@mysql.com
0c15039e74 Fix for bug #13525 "Rename table does not keep info of triggers".
Let us transfer triggers associated with table when we rename it (but only if
we are not changing database to which table belongs, in the latter case we will
emit error).
2006-02-24 23:50:36 +03:00
konstantin@mysql.com
af62c4a959 Merge mysql.com:/opt/local/work/mysql-4.1-13134
into  mysql.com:/opt/local/work/mysql-5.0-runtime
2006-02-24 00:00:15 +03:00