database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-30 16:24:05 +03:00
Code Activity

BUG#26881 - Large MERGE tables report incorrect specification when no

Browse Source 
differences in tables
Certain merge tables were wrongly reported as having incorrect definition:
- Some fields that are 1 byte long (e.g. TINYINT, CHAR(1)), might
  be internally casted (in certain cases) to a different type on a
  storage engine layer. (affects 4.1 and up)
- If tables in a merge (and a MERGE table itself) had short VARCHAR column (less
  than 4 bytes) and at least one (but not all) tables were ALTER'ed (even to an
  identical table: ALTER TABLE xxx ENGINE=yyy), table definitions went ouf of
  sync. (affects 4.1 only)

This is fixed by relaxing a check for underlying conformance and setting
field type to FIELD_TYPE_STRING in case varchar is shorter than 4
when a table is created.


myisam/mi_create.c:
  Added a comment.
mysql-test/r/merge.result:
  A test case for bug#26881.
mysql-test/t/merge.test:
  A test case for bug#26881.
sql/ha_myisam.cc:
  Relaxed some checks performed by check_definition():
  As comparing of fulltext keys (and key segments) is not yet implemented,
  only return an error in case one of keys is fulltext and other is not.
  Otherwise, if both keys are fulltext, accept them as is.
  
  As comparing of spatial keys (and key segments) is not yet implemented,
  only return an error in case one of keys is spatial and other is not.
  Otherwise, if both keys are spatial, accept them as is.
  
  A workaround to handle situation when field is casted from FIELD_SKIP_ZERO
  to FIELD_NORMAL. This could happen only in case field length is 1 and row
  format is fixed.
sql/sql_parse.cc:
  When a table that has varchar field shorter than 4 is created, field type is
  set to FIELD_TYPE_VAR_STRING. Later, when a table is modified using alter
  table, field type is changed to FIELD_TYPE_STRING (see Field_string::type).
  That means HA_OPTION_PACK_RECORD flag might be lost and thus null_bit might
  be shifted by alter table, in other words alter table doesn't create 100%
  equal table definition.
  
  This is usually not a problem, since when a table is created/altered,
  definition on a storage engine layer is based on one that is passed from
  sql layer. But it is a problem for merge engine - null_bit is shifted when
  a table (merge or underlying) is altered.
  
  Set field type to FIELD_TYPE_STRING in case FIELD_TYPE_VAR_STRING is shorter
  than 4 when a table is created as it is done in Field::type.
This commit is contained in:
unknown
2007-03-13 18:02:06 +04:00
parent e266365cad
commit 969b71653d
5 changed files with 77 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
mysql-test/r/merge.result
View File

@ -806,3 +806,16 @@ CREATE TABLE t2(c1 INT) ENGINE=MERGE UNION=(t1);
INSERT DELAYED INTO t2 VALUES(1);
ERROR HY000: Table storage engine for 't2' doesn't have this option
DROP TABLE t1, t2;
CREATE TABLE t1(c1 VARCHAR(1));
CREATE TABLE m1 LIKE t1;
ALTER TABLE m1 ENGINE=MERGE UNION=(t1);
SELECT * FROM m1;
c1
DROP TABLE t1, m1;
CREATE TABLE t1(c1 VARCHAR(4), c2 TINYINT, c3 TINYINT, c4 TINYINT,
c5 TINYINT, c6 TINYINT, c7 TINYINT, c8 TINYINT, c9 TINYINT);
CREATE TABLE m1 LIKE t1;
ALTER TABLE m1 ENGINE=MERGE UNION=(t1);
SELECT * FROM m1;
c1 c2 c3 c4 c5 c6 c7 c8 c9
DROP TABLE t1, m1;