MySQL Bugs: #19100: alter table ko (offline) with partition by key

Bug #19100	alter table ko (offline) with partition by key
Submitted:	14 Apr 2006 11:34	Modified:	28 Jun 2006 22:42
Reporter:	patrice audigou	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	5.1.8.beta	OS:	Linux (RedHat9)
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
alter table doesn't work with table created with partition by key :
we try to change the type of a field from varbinary(255) to binary(255) ; an error 1114 is detected .

mysql> describe IMSI;
+-----------------+-----------------------+------+-----+---------+-------+
| Field           | Type                  | Null | Key | Default | Extra |
+-----------------+-----------------------+------+-----+---------+-------+
| mykey           | int(10) unsigned      | NO   | PRI |         |       |
| vvBin           | varbinary(255)        | YES  |     |         |       |
| vvchar          | varchar(255)          | YES  |     |         |       |
| vvlBin          | varbinary(256)        | YES  |     |         |       |
| vvlchar         | varchar(256)          | YES  |     |         |       |
| vchar           | char(255)             | YES  |     |         |       |
| vbinary         | binary(255)           | YES  |     |         |       |
| vUnsigned       | int(10) unsigned      | YES  |     |         |       |
| vBigunsigned    | bigint(20) unsigned   | YES  |     |         |       |
| vMediumunsigned | mediumint(8) unsigned | YES  |     |         |       |
| vTinyunsigned   | tinyint(3) unsigned   | YES  |     |         |       |
| vSmallunsigned  | smallint(5) unsigned  | YES  |     |         |       |
| vBigint         | bigint(20)            | YES  |     |         |       |
| vMediumint      | mediumint(9)          | YES  |     |         |       |
| vInt            | int(11)               | YES  |     |         |       |
| vSmallint       | smallint(6)           | YES  |     |         |       |
| vTinyint        | tinyint(4)            | YES  |     |         |       |
| vBit            | bit(10)               | YES  |     |         |       |
+-----------------+-----------------------+------+-----+---------+-------+
18 rows in set (0.01 sec)
 
mysql> alter table IMSI modify vvBin binary(255);
ERROR 1114 (HY000): The table '#sql-614_1c' is full
mysql>

If we create the table without the clause partition by key, the test is OK.

How to repeat:
See above.

I was not able to reproduce this with current 5.0 bitkeeper sources,
could you please add SHOW CREATE TABLE output so that i can test
with exactly the same table definition that you are using?

To create the table, we use a .sql file doing that :
drop table if exists  IMSI;
create table IMSI (
                mykey INT UNSIGNED NOT NULL,
vvBin           VARBINARY(255),
vvchar          Varchar(255),
vvlBin          Varbinary(256),
vvlchar         Varchar(256),
vchar           CHAR(255),
vbinary         BINARY(255),
vUnsigned        INT UNSIGNED,
vBigunsigned    BIGINT UNSIGNED,
vMediumunsigned MEDIUMINT UNSIGNED,
vTinyunsigned   TINYINT UNSIGNED,
vSmallunsigned  SMALLINT UNSIGNED,
vBigint         BIGINT,
vMediumint      MEDIUMINT,
vInt            INT,
vSmallint       SMALLINT,
vTinyint        TINYINT,
vBit            BIT(10),
PRIMARY KEY USING HASH (mykey) ) engine=ndb PARTITION BY KEY (mykey);

It seems that the problem happens when we do several operations on the same column of the table.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I still couldn't reproduce this using the given CREATE and ALTER statements,
what i'm suspecting here is that there is just not enough space left in your
setup to create a temp. copy of the table (which is the way ALTER TABLE
works when changing the table schema)

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Which feedback are you waiting for ?