Commit graph

784 commits

Author SHA1 Message Date
unknown
eeb8d4c8b4 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.


sql/sql_table.cc:
  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
unknown
128c3942a8 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.


mysql-test/r/information_schema_db.result:
  test case
mysql-test/t/information_schema_db.test:
  test case
sql/sql_lex.cc:
  To simplify saving/resetting and restoring part of LEX which
  affects and is affected by the process of opening tables and
  views we moved it to new class Query_tables_list and made LEX
  descendant of this class. Also introduced two LEX methods 
  which can be used to save and reset or to restore this state.
sql/sql_lex.h:
  To simplify saving/resetting and restoring part of LEX which
  affects and is affected by the process of opening tables and
  views we moved it to new class Query_tables_list and made LEX
  descendant of this class. Also introduced two LEX methods 
  which can be used to save and reset or to restore this state.
sql/sql_show.cc:
  Now in get_all_tables() routine we properly save/reset and
  restore part of LEX (statement table list and information
  about routines used) which affects and is affected by the
  process of opening tables and views.
sql/sql_table.cc:
  Now we clean-up LEX after opening table (view) in two stages.
  In the first stage we call LEX::cleanup_after_one_table_open()
  to clean-up selects lists and derived tables state. In the
  second stage which happens after close_thread_tables() is
  invoked we call Query_tables_list::reset_query_tables_list(FALSE)
  to rollback changes in Query_tables_list.
2006-05-30 10:45:23 +05:00
unknown
c06d757e8e Merge svojtovich@bk-internal.mysql.com:/home/bk/mysql-5.0
into  april.(none):/home/svoj/devel/mysql/BUG17001/mysql-5.0


sql/sql_table.cc:
  Auto merged
2006-05-24 15:13:49 +05:00
unknown
7f20ecc7ec 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.


sql/sql_table.cc:
  Ensure that running ALTER TABLE on tables created by earlier
  MySQL versions recreates data files.
2006-05-16 18:37:23 +05:00
unknown
2ce5e54e0a Merge mysql.com:/opt/local/work/mysql-5.0-root
into  mysql.com:/opt/local/work/mysql-5.0-runtime-merge


mysql-test/mysql-test-run.pl:
  Auto merged
mysql-test/r/im_options_set.result:
  Auto merged
mysql-test/r/im_options_unset.result:
  Auto merged
mysql-test/r/trigger-grant.result:
  Auto merged
sql/item.cc:
  Auto merged
sql/item_func.cc:
  Auto merged
sql/item_func.h:
  Auto merged
sql/mysql_priv.h:
  Auto merged
sql/sp_head.cc:
  Auto merged
sql/sql_parse.cc:
  Auto merged
sql/share/errmsg.txt:
  Auto merged
sql/sql_table.cc:
  Auto merged
sql/sql_yacc.yy:
  Auto merged
2006-05-15 00:51:12 +04:00
unknown
f61748b796 Merge acurtis@bk-internal:/home/bk/mysql-5.0-engines
into  xiphis.org:/home/antony/work2/p1-bug10952.1


sql/handler.h:
  Auto merged
sql/sql_table.cc:
  Auto merged
2006-05-09 13:34:31 -07:00
unknown
6116d0176b 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.


mysql-test/r/blackhole.result:
  test for bug#10952
mysql-test/r/merge.result:
  test for bug#10952
mysql-test/t/blackhole.test:
  test for bug#10952
mysql-test/t/merge.test:
  test for bug#10952
sql/ha_blackhole.cc:
  Bug#10952
    shouldn't be able to alter a table into a blackhole
sql/ha_myisammrg.cc:
  Bug#10952
    shouldn't be able to alter a table into a merge
sql/handler.h:
  Bug#10952
    new handlerton flag
sql/sql_table.cc:
  Bug#10952
    If alter is changing engine, check if new engine allows creating table
    via ALTER statement.
2006-05-09 13:31:46 -07:00
unknown
cb5d6dbf51 Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  mysql.com:/home/dlenev/mysql-5.0-bg12472


sql/mysql_priv.h:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_insert.cc:
  Auto merged
sql/sql_table.cc:
  Auto merged
mysql-test/r/sp.result:
  Manual merge.
mysql-test/t/sp.test:
  Manual merge.
2006-05-09 16:48:23 +04:00
unknown
4f15a043e2 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.


mysql-test/r/sp.result:
  Added tests for bugs#12472/#15137 'CREATE TABLE ... SELECT ... which
  explicitly or implicitly uses stored function gives "Table not locked" error'
mysql-test/t/sp.test:
  Added tests for bugs#12472/#15137 'CREATE TABLE ... SELECT ... which
  explicitly or implicitly uses stored function gives "Table not locked" error'
sql/mysql_priv.h:
  Added flag which can be passed to open_table() routine in order to ignore
  set of locked tables and prelocked mode.
  We don't need declaration of create_table_from_items() any longer as it was
  moved into sql_insert.cc and made static.
sql/sql_base.cc:
  open_table():
    Added flag which allows open table ignoring set of locked tables and
    prelocked mode.
sql/sql_insert.cc:
  Moved create_table_from_items() from sql_table.cc to sql_insert.cc as it was
  not used outside of sql_insert.cc and contains code which is specific for
  CREATE TABLE ... SELECT.
  Also now when we are executing CREATE TABLE ... SELECT ... statement which
  SELECT part requires execution in prelocked mode we ignore set of locked
  tables in order to get access to the table we just have created.
  We probably don't want to do this if we are under real LOCK TABLES since
  it will widen window for deadlock too much.
sql/sql_table.cc:
  Moved create_table_from_items() routine into sql_insert.cc, since it was not
  used anywhere outside of this file and contains logic which is specific for
  CREATE TABLE ... SELECT statement.
2006-05-09 16:39:11 +04:00
unknown
46e54f244c Merge bk@192.168.21.1:mysql-5.0
into mysql.com:/home/hf/work/mysql-5.0.mrg


sql/sql_table.cc:
  Auto merged
2006-05-04 02:17:17 +05:00
unknown
b5732e7c8c Merge pnousiainen@bk-internal.mysql.com:/home/bk/mysql-4.1
into  mysql.com:/space/pekka/ndb/version/my50


mysql-test/r/ndb_blob.result:
  Auto merged
mysql-test/t/ndb_blob.test:
  Auto merged
ndb/include/kernel/signaldata/TcKeyReq.hpp:
  Auto merged
ndb/include/ndbapi/NdbBlob.hpp:
  Auto merged
ndb/src/ndbapi/NdbBlob.cpp:
  Auto merged
ndb/test/ndbapi/testBlobs.cpp:
  Auto merged
sql/sql_table.cc:
  Auto merged
ndb/tools/delete_all.cpp:
  nuts
2006-05-03 23:17:16 +02:00
unknown
66edfe285a merging fix 2006-05-03 17:43:32 +05:00
unknown
83c8e2c910 merging
sql/handler.h:
  Auto merged
sql/sql_table.cc:
  Auto merged
2006-05-03 16:42:39 +05:00
unknown
0a9c02f106 merging
mysql-test/mysql-test-run.pl:
  Auto merged
mysql-test/mysql-test-run.sh:
  Auto merged
mysql-test/r/analyze.result:
  Auto merged
mysql-test/t/analyze.test:
  Auto merged
mysql-test/t/mysql_client_test.test:
  Auto merged
mysql-test/t/mysqltest.test:
  Auto merged
2006-05-03 16:33:42 +05:00
unknown
bb95643f73 Merge mysql.com:/home/hf/work/mysql-4.1.15225
into mysql.com:/home/hf/work/mysql-4.1.mrg


sql/sql_table.cc:
  Auto merged
2006-05-03 15:51:19 +05:00
unknown
7400f10a88 Merge rkalimullin@bk-internal.mysql.com:/home/bk/mysql-4.1
into  mysql.com:/usr/home/ram/work/4.1.b7643


sql/sql_table.cc:
  Auto merged
2006-05-02 11:33:26 +05:00
unknown
a223550fa1 Merge zippy.(none):/home/cmiller/work/mysql/merge/tmp_merge
into  zippy.(none):/home/cmiller/work/mysql/merge/mysql-5.0


mysql-test/r/null.result:
  Auto merged
mysql-test/t/null.test:
  Auto merged
sql/sql_table.cc:
  Merge.
2006-05-01 09:46:00 -04:00
unknown
dd68976a24 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.


mysql-test/r/null.result:
  Add test case
mysql-test/t/null.test:
  Add test case
sql/sql_table.cc:
  No longer blindly dereference pointer of the string representation of the
  values, where "NULL" is NUL. Raise INVALID DEFAULT error messages where
  appropriate.
  
  Note that the -O1 optimization flag made debugging this extremely tricky, with
  misleading results, and that removing it from the Makefile during debugging can
  be invaluable.
2006-04-28 12:15:29 -04:00
unknown
09ad4efa5d Fix for bug #7643: ALTER TABLE fails for CSV, EXAMPLE, ARCHIVE engines
sql/sql_table.cc:
  Fix for bug #7643: ALTER TABLE fails for CSV, EXAMPLE, ARCHIVE engines
    - issue an ER_NOT_SUPPORTED_YET if an engine doesn't support ALTER TABLE.
2006-04-25 15:27:28 +05:00
unknown
f01b0ac221 bug #15860 (SPATIAL keys in INNODB)
mysql-test/r/innodb.result:
  result added
mysql-test/t/innodb.test:
  testcase
sql/ha_myisam.cc:
  HA_CAN_RTREEKEYS added to ha_myisam
sql/handler.h:
  HA_CAN_RTREEKEYS defined
sql/share/errmsg.txt:
  error message added
sql/sql_table.cc:
  check that the handler allows SPATIAL keys
2006-04-12 22:05:23 +05:00
unknown
e0708e2c11 Manual merge
myisam/mi_search.c:
  Auto merged
mysql-test/t/ctype_utf8.test:
  Auto merged
2006-03-30 17:14:55 +04:00
unknown
ff4de90501 Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-4.1
into sunlight.local:/local_work/15560-bug-4.1-mysql


sql/sql_table.cc:
  Auto merged
2006-03-30 10:22:03 +04:00
unknown
600a17635e post-merge fix 2006-03-30 09:13:25 +05:00
unknown
a7431720ce Merge
mysql-test/t/create.test:
  Auto merged
sql/sql_table.cc:
  Auto merged
mysql-test/r/create.result:
  SCCS merged
2006-03-30 08:13:28 +05:00
unknown
b25315469e 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.


mysql-test/t/func_gconcat.test:
  Added test for bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
mysql-test/r/func_gconcat.result:
  Added test for bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
sql/sql_table.cc:
  Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
  Added 0 as a last parameter to create_tmp_field()  to force old behaviour.
sql/sql_select.cc:
  Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
  
  Added the flag 'make_copy_field' to create_tmp_field(), so that for Item_result_field descendants create_tmp_field() sets the item's result field as a source field and deny resetting that result field to a new value.
sql/sql_class.h:
  Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
  Added the flag 'force_copy_fields' to the structure TMP_TABLE_PARAM in order to make create_tmp_field() force the creation of 'copy_field' objects.
sql/mysql_priv.h:
  Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
  Added the bool parameter 'make_copy_field' to create_tmp_field().
sql/item_sum.cc:
  Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
  Added initialization of the force_copy_fields flag and passing it to create_tmp_table() through TMP_TBLE_PARAM in the Item_func_group_concat and Item_sum_count_distinct member functions.
sql/item_sum.h:
  Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
  Added the flag 'force_copy_fields' to the Item_func_group_concat and Item_sum_count_distinct classes.
2006-03-29 23:30:34 +04:00
unknown
4af4e1e704 Fix for bug#15316 SET value having comma not correctly handled
disallow the use of comma in SET members


mysql-test/r/create.result:
  Fix for bug#15316 SET value having comma not correctly handled
   test case
mysql-test/t/create.test:
  Fix for bug#15316 SET value having comma not correctly handled
   test case
2006-03-29 19:52:26 +05:00
unknown
bb7e682809 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.


sql/sql_table.cc:
  mysql_alter_table():
    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
unknown
a389ec0b1b 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).
.


mysql-test/r/trigger.result:
  Added test-case covering handling of triggers when one does ALTER TABLE which
  should move table to different database.
mysql-test/t/trigger.test:
  Added test-case covering handling of triggers when one does ALTER TABLE which
  should move table to different database.
sql/sql_table.cc:
  mysql_alter_table():
    Removal of strdup() which is no longer necessary allows us to preserve
    nice assumption that "(new_db != db || new_table != table_name) indicates
    that table will be renamed. So now we really can use this condition to
    avoid updating trigger definitions when table is not renamed.
    Note that we can't use (alter_info->flags & ALTER_RENAME) condition instead
    since it can be also true when we do "ALTER TABLE t1 RENAME TO t1".
sql/sql_trigger.cc:
  Table_triggers_list::change_table_name():
    Mentioned assumption that subject table is not renamed to itself in method
    description. Added DBUG_ASSERT() to catch wrong usage of this method.
mysql-test/r/trigger-trans.result:
  New BitKeeper file ``mysql-test/r/trigger-trans.result''
mysql-test/t/trigger-trans.test:
  New BitKeeper file ``mysql-test/t/trigger-trans.test''
2006-03-24 14:58:18 +03:00
unknown
6e7d47e243 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  mysql.com:/home/dlenev/src/mysql-5.0-bg13525


sql/field.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_parse.cc:
  Auto merged
sql/sql_table.cc:
  Auto merged
sql/sql_select.h:
  Manual merge.
2006-02-27 20:00:03 +03:00
unknown
ac24b2b728 Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  mysql.com:/home/dlenev/src/mysql-5.0-bg13525


sql/sql_table.cc:
  Auto merged
2006-02-26 21:20:13 +03:00
unknown
1c93eeaa16 Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  mysql.com:/home/dlenev/src/mysql-5.0-bg13525


sql/sql_table.cc:
  Auto merged
sql/sql_trigger.cc:
  Auto merged
sql/sql_trigger.h:
  Auto merged
sql/sql_yacc.yy:
  Auto merged
mysql-test/r/trigger.result:
  SCCS merged
mysql-test/t/trigger.test:
  SCCS merged
2006-02-26 16:38:48 +03:00
unknown
f8386dfa48 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).


mysql-test/r/trigger.result:
  Added test for bug #13525 "Rename table does not keep info of triggers".
mysql-test/t/trigger.test:
  Added test for bug #13525 "Rename table does not keep info of triggers".
sql/sql_rename.cc:
  rename_tables():
    Now after renaming table's .FRM file and updating handler data we call
    Table_triggers_list::change_table_name() which is reponsible for
    updating .TRG and .TRN files.
sql/sql_table.cc:
  mysql_alter_table():
    Now in case when ALTER should rename table we call
    Table_triggers_list::change_table_name() which is responsible
    for updating .TRG and .TRN files after renaming table.
sql/sql_trigger.cc:
  Added Table_triggers_list::change_table_name() method and
  change_table_name_in_triggers()/trignames() methods responsible for updating
  .TRG and .TRN files for table during its renaming.
  
  Two small cleanups - removed versioning for .TRG files (since it was not working
  before anyway) and emphasized that type of lock specified in tables list is
  unimportant for DROP TABLE (since this statement uses name-locking).
sql/sql_trigger.h:
  Table_triggers_list:
    Added on_table_names_list member to store pointers and lenghts of
    "ON table_name" parts in triggers' definitions to be able easily
    change them during RENAME TABLE.
    Added change_table_name() method and change_table_name_in_trignames/triggers()
    helper methods responsible for updating .TRG and .TRN files.
sql/sql_yacc.yy:
  trigger_tail:
    To be able properly update triggers' definitions with new table names
    when renaming tables we need to know where in CREATE TRIGGER statement
    "ON db_name.table_name" part resides.
    Small cleanup - let us emphasize that for CREATE TRIGGER statement 
    lock type which is specified in table list is unimportant since
    name-locking is used.
2006-02-24 23:50:36 +03:00
unknown
9519987cf0 Merge mysql.com:/opt/local/work/mysql-4.1-13134
into  mysql.com:/opt/local/work/mysql-5.0-runtime


mysql-test/t/heap.test:
  Auto merged
mysql-test/r/heap.result:
  Manual merge (use local)
mysql-test/r/ps.result:
  Manual merge (use local)
mysql-test/t/ps.test:
  Manual merge.
sql/field.cc:
  Manual merge.
sql/field.h:
  Manual merge.
sql/sql_parse.cc:
  Manual merge.
sql/sql_table.cc:
  Manual merge.
2006-02-24 00:00:15 +03:00
unknown
9cf3f255bd A fix and a test case for Bug#13134 "Length of VARCHAR() utf8
column is increasing when table is recreated with PS/SP":
make use of create_field::char_length more consistent in the code.
Reinit create_field::length from create_field::char_length
for every execution of a prepared statement (actually fixes the 
bug).


mysql-test/r/ps.result:
  Test results fixed (Bug#13134)
mysql-test/t/ps.test:
  A test case for Bug#13134 "Length of VARCHAR() utf8 column is 
  increasing when table is recreated with PS/SP"
sql/field.cc:
  Move initialization of create_field::char_length to the constructor
  of create_field.
sql/field.h:
  Rename chars_length to char_length (to be consistent with
  how this term is used throughout the rest of the code).
sql/sql_parse.cc:
  Initialize char_length in add_field_to_list. This function
  effectively works as another create_field constructor.
sql/sql_table.cc:
  Reinit length from char_length for every field in 
  mysql_prepare_table. This is not needed if we're executing
  a statement for the first time, however, at subsequent executions
  length contains the number of bytes, not characters (as it's expected 
  to).
2006-02-21 19:52:20 +03:00
unknown
71ee8615c3 Fixed bug#17530: Incorrect key truncation on table creation caused server crash.
When a too long field is used for a key, only a prefix part of the field is 
used. Length is reduced to the max key length allowed for storage. But if the
field have a multibyte charset it is possible to break multibyte char
sequence. This leads to the failed assertion in the innodb code and 
server crash when a record is inserted.

The make_prepare_table() now aligns truncated key length to the boundary of
multibyte char.


mysql-test/t/create.test:
  Added test case for bug#17530: Incorrect key truncation on table creation caused server crash.
mysql-test/r/create.result:
  Added test case for bug#17530: Incorrect key truncation on table creation caused server crash.
sql/sql_table.cc:
  Fixed bug#17530: Incorrect key truncation on table creation caused server crash.
  The make_prepare_table() now aligns truncated key length to the boundary of
  multibyte char.
2006-02-21 18:09:32 +03:00
unknown
b23aa5c0be Merge bk@192.168.21.1:mysql-4.1
into mysql.com:/home/hf/work/mysql-4.1.15225


sql/sql_table.cc:
  Auto merged
2006-02-20 18:01:59 +04:00
unknown
96b4449370 Merge bk@192.168.21.1:mysql-5.0
into mysql.com:/home/hf/work/mysql-5.0.w2645


sql/sql_table.cc:
  Auto merged
2006-02-17 10:56:54 +04:00
unknown
bf84040458 WL#2645 (CHECK TABLE FOR UPGRADE)
necessary implementation in the server
mysql_upgrade script added


client/mysqlcheck.c:
  --check-upgrade option added
include/my_base.h:
  errcode added
include/myisam.h:
  option added
scripts/Makefile.am:
  mysql_upgrade script added
sql/handler.cc:
  checks for old types/bugs added
sql/handler.h:
  declarations regarding checks for upgrade
sql/lex.h:
  sym added
sql/share/errmsg.txt:
  error message added
sql/slave.cc:
  now ha_repair is for public use
sql/sql_table.cc:
  upgrade in ha_repair implemented
sql/sql_yacc.yy:
  CHECK ... FOR UPGRADE added to syntax
2006-02-17 10:52:32 +04:00
unknown
08394605dc Bug#8841 - CHECKSUM TABLE is broken in MyISAM
There are (at least) two implementations of the checksum
computation. One is in MyISAM for the quick checksum. It
is executed on every row change. The other is in the
SQL layer for the extended checksum. It retrieves all rows
of a table via the respective storage engine.

In former MySQL versions varchars were stored with their 
maximum length, but now with their real length similar to
blobs.

This change had been forgotten to take care of in the
extended checksum calculation. Hence too much data was
checksumed. In MyISAM this change had been taken care of 
already. Only the real data is included in the checksum.

I changed mysql_checksum_table() so that it uses the
length information of true varchar fields instead
of the field length like in former varchar 
implementations.


mysql-test/r/innodb.result:
  Bug#8841 - CHECKSUM TABLE is broken in MyISAM
  Fixed test results.
mysql-test/r/myisam.result:
  Bug#8841 - CHECKSUM TABLE is broken in MyISAM
  Fixed test results.
sql/sql_table.cc:
  Bug#8841 - CHECKSUM TABLE is broken in MyISAM
  Changed mysql_checksum_table() so that it uses the
  length information of true varchar fields instead
  of the field length like in former varchar 
  implementations.
2006-02-01 16:46:44 +01:00
unknown
490fbdb63e Merge a193-229-222-105.elisa-laajakaista.fi:/home/my/bk/mysql-4.1
into  a193-229-222-105.elisa-laajakaista.fi:/home/my/bk/mysql-5.0


mysql-test/r/create.result:
  Auto merged
mysql-test/t/create.test:
  Auto merged
sql/sql_table.cc:
  Auto merged
2006-01-16 21:31:22 +02:00
unknown
f41b7bca6c Merge
mysql-test/r/create.result:
  Auto merged
mysql-test/t/create.test:
  Auto merged
sql/sql_table.cc:
  SCCS merged
2006-01-16 16:21:41 +01:00
unknown
7f397ffd95 BUG#13835: max key length is 1000 bytes when trying to create a fulltext index
Allow fulltext index on VARCHAR columns longer than max key length.


mysql-test/r/fulltext.result:
  A test case for BUG#13835 added.
mysql-test/t/fulltext.test:
  A test case for BUG#13835 added.
sql/sql_table.cc:
  Allow fulltext index on VARCHAR columns longer than max key length.
2006-01-13 21:25:12 +04:00
unknown
48450d8a2b Fix for bug #15225 (ANALYZE temporary has no effect)
mysql-test/r/analyze.result:
  test result fixed
mysql-test/t/analyze.test:
  test case added
sql/sql_table.cc:
  we don't need to remove temporary table from the cache,
  but we need to reload it's info
2005-12-10 18:02:36 +04:00
unknown
d9c233ae76 better error for optimize/repair/etc a view 2005-12-05 12:08:30 +01:00
unknown
da8b9967a8 this has nothing to do with the bug#13012.
it's about mysql_admin_commands not being reexecution-safe
(and CHECK still isn't)


mysql-test/r/sp-error.result:
  optimize is now allowed in SP
mysql-test/r/sp.result:
  test repair/optimize/analyze in SP
mysql-test/t/backup.test:
  clean up after itself
mysql-test/t/sp-error.test:
  optimize is now allowed in SP
mysql-test/t/sp.test:
  test repair/optimize/analyze in SP
sql/sp_head.cc:
  all mysql_admin commands return result set
sql/sql_parse.cc:
  all mysql_admin commands modify table list and we should restore it for SP
sql/sql_table.cc:
  optimization - don't execute views when no view is expected/allowed
sql/sql_yacc.yy:
  optimize is now allowed in SP
2005-12-03 15:02:09 +01:00
unknown
88822b356a Merge bk@192.168.21.1:mysql-5.0
into mysql.com:/home/hf/work/mysql-5.0.14693


sql/sql_table.cc:
  Auto merged
2005-11-29 13:33:56 +04:00
unknown
2e79201c72 Post-merge fixes. 2005-11-25 18:53:55 +03:00
unknown
61e454c0a9 Merge mysql.com:/opt/local/work/mysql-4.1-root
into  mysql.com:/opt/local/work/mysql-5.0-root


mysql-test/r/ndb_alter_table.result:
  Auto merged
mysql-test/r/ndb_basic.result:
  Auto merged
mysql-test/t/select.test:
  Auto merged
sql/handler.cc:
  Auto merged
sql/mysql_priv.h:
  Auto merged
sql/table.cc:
  Auto merged
vio/vio.c:
  Auto merged
vio/viossl.c:
  Auto merged
include/my_base.h:
  Manual merge.
mysql-test/r/ps.result:
  Manual merge.
mysql-test/r/select.result:
  Manual merge.
mysql-test/t/ndb_alter_table.test:
  Manual merge.
mysql-test/t/ndb_basic.test:
  Manual merge.
mysql-test/t/ps.test:
  Manual merge.
sql-common/client.c:
  k	
sql/ha_ndbcluster.cc:
  Manual merge.
sql/item.cc:
  Manual merge.
sql/sql_table.cc:
  Manual merge.
2005-11-25 13:57:13 +03:00
unknown
2a1ae3a5e3 A fix and a test case for Bug#14410 "Crash in Enum or Set type in
CREATE TABLE and PS/SP": make sure that 'typelib' object for
ENUM values and 'Item_string' object for DEFAULT clause are 
created in the statement memory root.


mysql-test/r/ps.result:
  Test results has been fixed (Bug#14410)
mysql-test/t/ps.test:
  A test case for Bug#14410 "Crash in Enum or Set type in CREATE 
  TABLE and PS/SP"
sql/mysql_priv.h:
  typelib() function declaration has been changed.
sql/sql_table.cc:
  Supply the statement memory root to use in typelib() and
  safe_charset_converter() functions to ensure that objects 
  created during the first execution of CREATE TABLE statement
  are allocated in persistent memory of the statement.
sql/table.cc:
  Change typelib() function to require MEM_ROOT.
2005-11-25 13:25:31 +03:00
unknown
ae2dc30930 Fix for bug #14693 (ALTER COLUMN SET DEFAULT has no effect)
mysql-test/r/alter_table.result:
  test result
mysql-test/t/alter_table.test:
  test case
sql/sql_table.cc:
  we should set the flag with the ALTER requirements
2005-11-24 20:24:45 +04:00