Commit 46fc7653 authored by unknown's avatar unknown

Bug #17701, ALTER TABLE t1 ADD PARTITION for PARTITION BY LIST hangs test

- code wrongly tries to do a "fast alter partition", although not supported


sql/handler.h:
  moved defines
sql/sql_partition.h:
  moved defines
parent 5f06d173
......@@ -130,6 +130,34 @@
#define HA_ONLINE_DROP_UNIQUE_INDEX (1L << 9) /*drop uniq. online*/
#define HA_ONLINE_ADD_PK_INDEX (1L << 10)/*add prim. online*/
#define HA_ONLINE_DROP_PK_INDEX (1L << 11)/*drop prim. online*/
/*
HA_PARTITION_FUNCTION_SUPPORTED indicates that the function is
supported at all.
HA_FAST_CHANGE_PARTITION means that optimised variants of the changes
exists but they are not necessarily done online.
HA_ONLINE_DOUBLE_WRITE means that the handler supports writing to both
the new partition and to the old partitions when updating through the
old partitioning schema while performing a change of the partitioning.
This means that we can support updating of the table while performing
the copy phase of the change. For no lock at all also a double write
from new to old must exist and this is not required when this flag is
set.
This is actually removed even before it was introduced the first time.
The new idea is that handlers will handle the lock level already in
store_lock for ALTER TABLE partitions.
HA_PARTITION_ONE_PHASE is a flag that can be set by handlers that take
care of changing the partitions online and in one phase. Thus all phases
needed to handle the change are implemented inside the storage engine.
The storage engine must also support auto-discovery since the frm file
is changed as part of the change and this change must be controlled by
the storage engine. A typical engine to support this is NDB (through
WL #2498).
*/
#define HA_PARTITION_FUNCTION_SUPPORTED (1L << 12)
#define HA_FAST_CHANGE_PARTITION (1L << 13)
#define HA_PARTITION_ONE_PHASE (1L << 14)
/*
Index scan will not return records in rowid order. Not guaranteed to be
......
......@@ -4011,7 +4011,7 @@ uint prep_alter_part_table(THD *thd, TABLE *table, ALTER_INFO *alter_info,
is freed by setting version to 0. table->s->version= 0 forces a
flush of the table object in close_thread_tables().
*/
uint flags;
uint flags= 0;
table->s->version= 0L;
if (alter_info->flags == ALTER_TABLE_REORG)
{
......@@ -4060,7 +4060,10 @@ uint prep_alter_part_table(THD *thd, TABLE *table, ALTER_INFO *alter_info,
my_error(ER_PARTITION_FUNCTION_FAILURE, MYF(0));
DBUG_RETURN(1);
}
*fast_alter_partition= flags ^ HA_PARTITION_FUNCTION_SUPPORTED;
*fast_alter_partition=
((flags & (HA_FAST_CHANGE_PARTITION | HA_PARTITION_ONE_PHASE)) != 0);
DBUG_PRINT("info", ("*fast_alter_partition: %d flags: 0x%x",
*fast_alter_partition, flags));
if (alter_info->flags & ALTER_ADD_PARTITION)
{
/*
......@@ -4660,7 +4663,6 @@ the generated partition syntax in a correct manner.
DBUG_ASSERT(FALSE);
}
*partition_changed= TRUE;
create_info->db_type= &partition_hton;
thd->lex->part_info= tab_part_info;
if (alter_info->flags == ALTER_ADD_PARTITION ||
alter_info->flags == ALTER_REORGANIZE_PARTITION)
......
......@@ -24,35 +24,6 @@
#define HA_CAN_PARTITION_UNIQUE (1 << 2)
#define HA_USE_AUTO_PARTITION (1 << 3)
/*
HA_PARTITION_FUNCTION_SUPPORTED indicates that the function is
supported at all.
HA_FAST_CHANGE_PARTITION means that optimised variants of the changes
exists but they are not necessarily done online.
HA_ONLINE_DOUBLE_WRITE means that the handler supports writing to both
the new partition and to the old partitions when updating through the
old partitioning schema while performing a change of the partitioning.
This means that we can support updating of the table while performing
the copy phase of the change. For no lock at all also a double write
from new to old must exist and this is not required when this flag is
set.
This is actually removed even before it was introduced the first time.
The new idea is that handlers will handle the lock level already in
store_lock for ALTER TABLE partitions.
HA_PARTITION_ONE_PHASE is a flag that can be set by handlers that take
care of changing the partitions online and in one phase. Thus all phases
needed to handle the change are implemented inside the storage engine.
The storage engine must also support auto-discovery since the frm file
is changed as part of the change and this change must be controlled by
the storage engine. A typical engine to support this is NDB (through
WL #2498).
*/
#define HA_PARTITION_FUNCTION_SUPPORTED (1L << 12)
#define HA_FAST_CHANGE_PARTITION (1L << 13)
#define HA_PARTITION_ONE_PHASE (1L << 14)
/*typedef struct {
ulonglong data_file_length;
ulonglong max_data_file_length;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment