You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

827 lines
17 KiB

Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
Bug#38804: Query deadlock causes all tables to be inaccessible. Problem was a mutex added in bug n 27405 for solving a problem with auto_increment in partitioned innodb tables. (in ha_partition::write_row over partitions file->ha_write_row) Solution is to use the patch for bug#33479, which refines the usage of mutexes for auto_increment. Backport of bug-33479 from 6.0: Bug-33479: auto_increment failures in partitioning Several problems with auto_increment in partitioning (with MyISAM, InnoDB. Locking issues, not handling multi-row INSERTs properly etc.) Changed the auto_increment handling for partitioning: Added a ha_data variable in table_share for storage engine specific data such as auto_increment value handling in partitioning, also see WL 4305 and using the ha_data->mutex to lock around read + update. The idea is this: Store the table's reserved auto_increment value in the TABLE_SHARE and use a mutex to, lock it for reading and updating it and unlocking it, in one block. Only accessing all partitions when it is not initialized. Also allow reservations of ranges, and if no one has done a reservation afterwards, lower the reservation to what was actually used after the statement is done (via release_auto_increment from WL 3146). The lock is kept from the first reservation if it is statement based replication and a multi-row INSERT statement where the number of candidate rows to insert is not known in advance (like INSERT SELECT, LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)). This should also lead to better concurrancy (no need to have a mutex protection around write_row in all cases) and work with any local storage engine.
17 years ago
  1. DROP TABLE IF EXISTS t1;
  2. # test without partitioning for reference
  3. CREATE TABLE t1 (
  4. c1 INT NOT NULL AUTO_INCREMENT,
  5. PRIMARY KEY (c1))
  6. ENGINE='InnoDB';
  7. SHOW CREATE TABLE t1;
  8. Table Create Table
  9. t1 CREATE TABLE `t1` (
  10. `c1` int(11) NOT NULL AUTO_INCREMENT,
  11. PRIMARY KEY (`c1`)
  12. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  13. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  14. AND TABLE_NAME='t1';
  15. AUTO_INCREMENT
  16. 1
  17. INSERT INTO t1 VALUES (2);
  18. INSERT INTO t1 VALUES (4);
  19. INSERT INTO t1 VALUES (NULL);
  20. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  21. AND TABLE_NAME='t1';
  22. AUTO_INCREMENT
  23. 6
  24. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  25. AND TABLE_NAME='t1';
  26. AUTO_INCREMENT
  27. 6
  28. INSERT INTO t1 VALUES (0);
  29. INSERT INTO t1 VALUES (5), (16);
  30. INSERT INTO t1 VALUES (17);
  31. INSERT INTO t1 VALUES (19), (NULL);
  32. INSERT INTO t1 VALUES (NULL), (10), (NULL);
  33. INSERT INTO t1 VALUES (NULL);
  34. SET INSERT_ID = 30;
  35. INSERT INTO t1 VALUES (NULL);
  36. UPDATE t1 SET c1 = 50 WHERE c1 = 17;
  37. UPDATE t1 SET c1 = 51 WHERE c1 = 19;
  38. FLUSH TABLES;
  39. UPDATE t1 SET c1 = 40 WHERE c1 = 50;
  40. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  41. AND TABLE_NAME='t1';
  42. AUTO_INCREMENT
  43. 31
  44. UPDATE t1 SET c1 = NULL WHERE c1 = 4;
  45. Warnings:
  46. Warning 1048 Column 'c1' cannot be null
  47. INSERT INTO t1 VALUES (NULL);
  48. INSERT INTO t1 VALUES (NULL);
  49. SELECT * FROM t1 ORDER BY c1;
  50. c1
  51. 0
  52. 2
  53. 5
  54. 6
  55. 10
  56. 20
  57. 22
  58. 23
  59. 25
  60. 30
  61. 31
  62. 32
  63. 40
  64. 51
  65. DROP TABLE t1;
  66. CREATE TABLE t1 (
  67. c1 INT NOT NULL AUTO_INCREMENT,
  68. PRIMARY KEY (c1))
  69. ENGINE='InnoDB';
  70. SHOW CREATE TABLE t1;
  71. Table Create Table
  72. t1 CREATE TABLE `t1` (
  73. `c1` int(11) NOT NULL AUTO_INCREMENT,
  74. PRIMARY KEY (`c1`)
  75. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  76. FLUSH TABLE;
  77. SHOW CREATE TABLE t1;
  78. Table Create Table
  79. t1 CREATE TABLE `t1` (
  80. `c1` int(11) NOT NULL AUTO_INCREMENT,
  81. PRIMARY KEY (`c1`)
  82. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  83. INSERT INTO t1 VALUES (4);
  84. FLUSH TABLE;
  85. SHOW CREATE TABLE t1;
  86. Table Create Table
  87. t1 CREATE TABLE `t1` (
  88. `c1` int(11) NOT NULL AUTO_INCREMENT,
  89. PRIMARY KEY (`c1`)
  90. ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1
  91. INSERT INTO t1 VALUES (NULL);
  92. FLUSH TABLE;
  93. SHOW CREATE TABLE t1;
  94. Table Create Table
  95. t1 CREATE TABLE `t1` (
  96. `c1` int(11) NOT NULL AUTO_INCREMENT,
  97. PRIMARY KEY (`c1`)
  98. ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=latin1
  99. DELETE FROM t1;
  100. INSERT INTO t1 VALUES (NULL);
  101. SHOW CREATE TABLE t1;
  102. Table Create Table
  103. t1 CREATE TABLE `t1` (
  104. `c1` int(11) NOT NULL AUTO_INCREMENT,
  105. PRIMARY KEY (`c1`)
  106. ) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=latin1
  107. SELECT * FROM t1 ORDER BY c1;
  108. c1
  109. 6
  110. TRUNCATE TABLE t1;
  111. INSERT INTO t1 VALUES (NULL);
  112. SHOW CREATE TABLE t1;
  113. Table Create Table
  114. t1 CREATE TABLE `t1` (
  115. `c1` int(11) NOT NULL AUTO_INCREMENT,
  116. PRIMARY KEY (`c1`)
  117. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  118. SELECT * FROM t1 ORDER BY c1;
  119. c1
  120. 1
  121. INSERT INTO t1 VALUES (100);
  122. INSERT INTO t1 VALUES (NULL);
  123. DELETE FROM t1 WHERE c1 >= 100;
  124. OPTIMIZE TABLE t1;
  125. Table Op Msg_type Msg_text
  126. test.t1 optimize note Table does not support optimize, doing recreate + analyze instead
  127. test.t1 optimize status OK
  128. SHOW CREATE TABLE t1;
  129. Table Create Table
  130. t1 CREATE TABLE `t1` (
  131. `c1` int(11) NOT NULL AUTO_INCREMENT,
  132. PRIMARY KEY (`c1`)
  133. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  134. DROP TABLE t1;
  135. # Simple test with NULL
  136. CREATE TABLE t1 (
  137. c1 INT NOT NULL AUTO_INCREMENT,
  138. PRIMARY KEY (c1))
  139. ENGINE='InnoDB'
  140. PARTITION BY HASH(c1)
  141. PARTITIONS 2;
  142. INSERT INTO t1 VALUES (NULL);
  143. SHOW CREATE TABLE t1;
  144. Table Create Table
  145. t1 CREATE TABLE `t1` (
  146. `c1` int(11) NOT NULL AUTO_INCREMENT,
  147. PRIMARY KEY (`c1`)
  148. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  149. /*!50100 PARTITION BY HASH (c1)
  150. PARTITIONS 2 */
  151. SELECT * FROM t1;
  152. c1
  153. 1
  154. DROP TABLE t1;
  155. # Test with sql_mode and first insert as 0
  156. CREATE TABLE t1 (
  157. c1 INT,
  158. c2 INT NOT NULL AUTO_INCREMENT,
  159. PRIMARY KEY (c2))
  160. ENGINE='InnoDB'
  161. PARTITION BY HASH(c2)
  162. PARTITIONS 2;
  163. INSERT INTO t1 VALUES (1, NULL);
  164. INSERT INTO t1 VALUES (1, 1), (99, 99);
  165. INSERT INTO t1 VALUES (1, NULL);
  166. SET @@session.sql_mode = 'NO_AUTO_VALUE_ON_ZERO';
  167. INSERT INTO t1 VALUES (1, 0);
  168. SELECT * FROM t1 ORDER BY c1, c2;
  169. c1 c2
  170. 1 0
  171. 1 1
  172. 1 2
  173. DROP TABLE t1;
  174. CREATE TABLE t1 (
  175. c1 INT,
  176. c2 INT NOT NULL AUTO_INCREMENT,
  177. PRIMARY KEY (c2))
  178. ENGINE='InnoDB'
  179. PARTITION BY HASH(c2)
  180. PARTITIONS 2;
  181. INSERT INTO t1 VALUES (1, 0);
  182. INSERT INTO t1 VALUES (1, 1), (1, NULL);
  183. INSERT INTO t1 VALUES (2, NULL), (4, 7);
  184. INSERT INTO t1 VALUES (1, NULL);
  185. SELECT * FROM t1 ORDER BY c1, c2;
  186. c1 c2
  187. 1 0
  188. 1 1
  189. 1 2
  190. 1 8
  191. 2 3
  192. 4 7
  193. SET @@session.sql_mode = '';
  194. DROP TABLE t1;
  195. # Simple test with NULL, 0 and explicit values both incr. and desc.
  196. CREATE TABLE t1 (
  197. c1 INT NOT NULL AUTO_INCREMENT,
  198. PRIMARY KEY (c1))
  199. ENGINE='InnoDB'
  200. PARTITION BY HASH(c1)
  201. PARTITIONS 2;
  202. INSERT INTO t1 VALUES (2), (4), (NULL);
  203. INSERT INTO t1 VALUES (0);
  204. INSERT INTO t1 VALUES (5), (16);
  205. INSERT INTO t1 VALUES (17), (19), (NULL);
  206. INSERT INTO t1 VALUES (NULL), (10), (NULL);
  207. INSERT INTO t1 VALUES (NULL), (9);
  208. INSERT INTO t1 VALUES (59), (55);
  209. INSERT INTO t1 VALUES (NULL), (90);
  210. INSERT INTO t1 VALUES (NULL);
  211. UPDATE t1 SET c1 = 150 WHERE c1 = 17;
  212. UPDATE t1 SET c1 = 151 WHERE c1 = 19;
  213. FLUSH TABLES;
  214. UPDATE t1 SET c1 = 140 WHERE c1 = 150;
  215. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  216. AND TABLE_NAME='t1';
  217. AUTO_INCREMENT
  218. 141
  219. UPDATE t1 SET c1 = NULL WHERE c1 = 4;
  220. Warnings:
  221. Warning 1048 Column 'c1' cannot be null
  222. INSERT INTO t1 VALUES (NULL);
  223. INSERT INTO t1 VALUES (NULL);
  224. SELECT * FROM t1 ORDER BY c1;
  225. c1
  226. 0
  227. 2
  228. 5
  229. 6
  230. 9
  231. 10
  232. 20
  233. 21
  234. 22
  235. 23
  236. 55
  237. 59
  238. 60
  239. 90
  240. 91
  241. 140
  242. 141
  243. 142
  244. 151
  245. DROP TABLE t1;
  246. # Test with auto_increment_increment and auto_increment_offset.
  247. CREATE TABLE t1 (
  248. c1 INT NOT NULL AUTO_INCREMENT,
  249. PRIMARY KEY (c1))
  250. ENGINE='InnoDB'
  251. PARTITION BY HASH(c1)
  252. PARTITIONS 2;
  253. SET @@session.auto_increment_increment = 10;
  254. SET @@session.auto_increment_offset = 5;
  255. INSERT INTO t1 VALUES (1);
  256. INSERT INTO t1 VALUES (NULL), (NULL), (NULL);
  257. SET @@session.auto_increment_increment = 5;
  258. SET @@session.auto_increment_offset = 3;
  259. INSERT INTO t1 VALUES (NULL);
  260. INSERT INTO t1 VALUES (33 + 1);
  261. INSERT INTO t1 VALUES (NULL);
  262. INSERT INTO t1 VALUES (38 + 2);
  263. INSERT INTO t1 VALUES (NULL);
  264. INSERT INTO t1 VALUES (43 + 3);
  265. INSERT INTO t1 VALUES (NULL);
  266. INSERT INTO t1 VALUES (48 + 4);
  267. INSERT INTO t1 VALUES (NULL);
  268. INSERT INTO t1 VALUES (53 + 5);
  269. INSERT INTO t1 VALUES (NULL);
  270. INSERT INTO t1 VALUES (63 + 6);
  271. INSERT INTO t1 VALUES (NULL);
  272. SET @@session.auto_increment_increment = 1;
  273. SET @@session.auto_increment_offset = 1;
  274. SELECT * FROM t1 ORDER BY c1;
  275. c1
  276. 1
  277. 5
  278. 15
  279. 25
  280. 33
  281. 34
  282. 38
  283. 40
  284. 43
  285. 46
  286. 48
  287. 52
  288. 53
  289. 58
  290. 63
  291. 69
  292. 73
  293. DROP TABLE t1;
  294. # Test reported auto_increment value
  295. CREATE TABLE t1 (
  296. c1 INT NOT NULL AUTO_INCREMENT,
  297. PRIMARY KEY (c1))
  298. ENGINE='InnoDB'
  299. PARTITION BY HASH (c1)
  300. PARTITIONS 2;
  301. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  302. AND TABLE_NAME='t1';
  303. AUTO_INCREMENT
  304. 1
  305. INSERT INTO t1 VALUES (2);
  306. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  307. AND TABLE_NAME='t1';
  308. AUTO_INCREMENT
  309. 3
  310. INSERT INTO t1 VALUES (4);
  311. INSERT INTO t1 VALUES (NULL);
  312. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  313. AND TABLE_NAME='t1';
  314. AUTO_INCREMENT
  315. 6
  316. INSERT INTO t1 VALUES (NULL);
  317. INSERT INTO t1 VALUES (17);
  318. INSERT INTO t1 VALUES (19);
  319. INSERT INTO t1 VALUES (NULL);
  320. INSERT INTO t1 VALUES (NULL);
  321. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  322. AND TABLE_NAME='t1';
  323. AUTO_INCREMENT
  324. 22
  325. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  326. AND TABLE_NAME='t1';
  327. AUTO_INCREMENT
  328. 22
  329. INSERT INTO t1 VALUES (10);
  330. SELECT * FROM t1 ORDER BY c1;
  331. c1
  332. 2
  333. 4
  334. 5
  335. 6
  336. 10
  337. 17
  338. 19
  339. 20
  340. 21
  341. INSERT INTO t1 VALUES (NULL);
  342. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  343. AND TABLE_NAME='t1';
  344. AUTO_INCREMENT
  345. 23
  346. INSERT INTO t1 VALUES (NULL);
  347. INSERT INTO t1 VALUES (15);
  348. INSERT INTO t1 VALUES (NULL);
  349. SELECT * FROM t1 ORDER BY c1;
  350. c1
  351. 2
  352. 4
  353. 5
  354. 6
  355. 10
  356. 15
  357. 17
  358. 19
  359. 20
  360. 21
  361. 22
  362. 23
  363. 24
  364. INSERT INTO t1 VALUES (NULL);
  365. DELETE FROM t1;
  366. INSERT INTO t1 VALUES (NULL);
  367. SHOW CREATE TABLE t1;
  368. Table Create Table
  369. t1 CREATE TABLE `t1` (
  370. `c1` int(11) NOT NULL AUTO_INCREMENT,
  371. PRIMARY KEY (`c1`)
  372. ) ENGINE=InnoDB AUTO_INCREMENT=27 DEFAULT CHARSET=latin1
  373. /*!50100 PARTITION BY HASH (c1)
  374. PARTITIONS 2 */
  375. SELECT * FROM t1 ORDER BY c1;
  376. c1
  377. 26
  378. TRUNCATE TABLE t1;
  379. INSERT INTO t1 VALUES (NULL);
  380. SHOW CREATE TABLE t1;
  381. Table Create Table
  382. t1 CREATE TABLE `t1` (
  383. `c1` int(11) NOT NULL AUTO_INCREMENT,
  384. PRIMARY KEY (`c1`)
  385. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  386. /*!50100 PARTITION BY HASH (c1)
  387. PARTITIONS 2 */
  388. SELECT * FROM t1 ORDER BY c1;
  389. c1
  390. 1
  391. INSERT INTO t1 VALUES (100);
  392. INSERT INTO t1 VALUES (NULL);
  393. DELETE FROM t1 WHERE c1 >= 100;
  394. OPTIMIZE TABLE t1;
  395. Table Op Msg_type Msg_text
  396. test.t1 optimize note Table does not support optimize, doing recreate + analyze instead
  397. test.t1 optimize status OK
  398. SHOW CREATE TABLE t1;
  399. Table Create Table
  400. t1 CREATE TABLE `t1` (
  401. `c1` int(11) NOT NULL AUTO_INCREMENT,
  402. PRIMARY KEY (`c1`)
  403. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  404. /*!50100 PARTITION BY HASH (c1)
  405. PARTITIONS 2 */
  406. DROP TABLE t1;
  407. # Test with two threads
  408. # con default
  409. CREATE TABLE t1 (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (c1))
  410. ENGINE = 'InnoDB'
  411. PARTITION BY HASH(c1)
  412. PARTITIONS 2;
  413. INSERT INTO t1 (c1) VALUES (2);
  414. INSERT INTO t1 (c1) VALUES (4);
  415. # con1
  416. INSERT INTO t1 (c1) VALUES (NULL);
  417. INSERT INTO t1 (c1) VALUES (10);
  418. # con default
  419. INSERT INTO t1 (c1) VALUES (NULL);
  420. INSERT INTO t1 (c1) VALUES (NULL);
  421. INSERT INTO t1 (c1) VALUES (19);
  422. INSERT INTO t1 (c1) VALUES (21);
  423. # con1
  424. INSERT INTO t1 (c1) VALUES (NULL);
  425. # con default
  426. INSERT INTO t1 (c1) VALUES (16);
  427. # con1
  428. INSERT INTO t1 (c1) VALUES (NULL);
  429. # con default
  430. INSERT INTO t1 (c1) VALUES (NULL);
  431. SELECT * FROM t1 ORDER BY c1;
  432. c1
  433. 2
  434. 4
  435. 5
  436. 10
  437. 11
  438. 12
  439. 16
  440. 19
  441. 21
  442. 22
  443. 23
  444. 24
  445. DROP TABLE t1;
  446. # Test with two threads + start transaction NO PARTITIONING
  447. # con default
  448. CREATE TABLE t1 (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (c1))
  449. ENGINE = 'InnoDB';
  450. START TRANSACTION;
  451. INSERT INTO t1 (c1) VALUES (2);
  452. INSERT INTO t1 (c1) VALUES (4);
  453. # con1
  454. START TRANSACTION;
  455. INSERT INTO t1 (c1) VALUES (NULL);
  456. INSERT INTO t1 (c1) VALUES (10);
  457. # con default
  458. INSERT INTO t1 (c1) VALUES (NULL);
  459. INSERT INTO t1 (c1) VALUES (NULL);
  460. INSERT INTO t1 (c1) VALUES (19);
  461. INSERT INTO t1 (c1) VALUES (21);
  462. # con1
  463. INSERT INTO t1 (c1) VALUES (NULL);
  464. # con default
  465. INSERT INTO t1 (c1) VALUES (16);
  466. # con1
  467. INSERT INTO t1 (c1) VALUES (NULL);
  468. SELECT * FROM t1 ORDER BY c1;
  469. c1
  470. 5
  471. 10
  472. 22
  473. 23
  474. COMMIT;
  475. SELECT * FROM t1 ORDER BY c1;
  476. c1
  477. 5
  478. 10
  479. 22
  480. 23
  481. # con default
  482. INSERT INTO t1 (c1) VALUES (NULL);
  483. SELECT * FROM t1 ORDER BY c1;
  484. c1
  485. 2
  486. 4
  487. 5
  488. 10
  489. 11
  490. 12
  491. 16
  492. 19
  493. 21
  494. 22
  495. 23
  496. 24
  497. COMMIT;
  498. SELECT * FROM t1 ORDER BY c1;
  499. c1
  500. 2
  501. 4
  502. 5
  503. 10
  504. 11
  505. 12
  506. 16
  507. 19
  508. 21
  509. 22
  510. 23
  511. 24
  512. DROP TABLE t1;
  513. # Test with two threads + start transaction
  514. # con default
  515. CREATE TABLE t1 (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (c1))
  516. ENGINE = 'InnoDB'
  517. PARTITION BY HASH(c1)
  518. PARTITIONS 2;
  519. START TRANSACTION;
  520. INSERT INTO t1 (c1) VALUES (2);
  521. INSERT INTO t1 (c1) VALUES (4);
  522. # con1
  523. START TRANSACTION;
  524. INSERT INTO t1 (c1) VALUES (NULL), (10);
  525. # con default
  526. INSERT INTO t1 (c1) VALUES (NULL), (NULL), (19);
  527. INSERT INTO t1 (c1) VALUES (21);
  528. # con1
  529. INSERT INTO t1 (c1) VALUES (NULL);
  530. # con default
  531. INSERT INTO t1 (c1) VALUES (16);
  532. # con1
  533. INSERT INTO t1 (c1) VALUES (NULL);
  534. SELECT * FROM t1 ORDER BY c1;
  535. c1
  536. 5
  537. 10
  538. 22
  539. 23
  540. COMMIT;
  541. SELECT * FROM t1 ORDER BY c1;
  542. c1
  543. 5
  544. 10
  545. 22
  546. 23
  547. # con default
  548. INSERT INTO t1 (c1) VALUES (NULL);
  549. SELECT * FROM t1 ORDER BY c1;
  550. c1
  551. 2
  552. 4
  553. 5
  554. 10
  555. 11
  556. 12
  557. 16
  558. 19
  559. 21
  560. 22
  561. 23
  562. 24
  563. COMMIT;
  564. SELECT * FROM t1 ORDER BY c1;
  565. c1
  566. 2
  567. 4
  568. 5
  569. 10
  570. 11
  571. 12
  572. 16
  573. 19
  574. 21
  575. 22
  576. 23
  577. 24
  578. DROP TABLE t1;
  579. # Test with another column after
  580. CREATE TABLE t1 (
  581. c1 INT NOT NULL AUTO_INCREMENT,
  582. c2 INT,
  583. PRIMARY KEY (c1,c2))
  584. ENGINE = 'InnoDB'
  585. PARTITION BY HASH(c2)
  586. PARTITIONS 2;
  587. INSERT INTO t1 VALUES (1, 0);
  588. INSERT INTO t1 VALUES (1, 1);
  589. INSERT INTO t1 VALUES (NULL, 1), (NULL, 2), (NULL, 3);
  590. INSERT INTO t1 VALUES (NULL, 3);
  591. INSERT INTO t1 VALUES (2, 0), (NULL, 2);
  592. INSERT INTO t1 VALUES (2, 2);
  593. INSERT INTO t1 VALUES (2, 22);
  594. INSERT INTO t1 VALUES (NULL, 2);
  595. SELECT * FROM t1 ORDER BY c1,c2;
  596. c1 c2
  597. 1 0
  598. 1 1
  599. 2 0
  600. 2 1
  601. 2 2
  602. 2 22
  603. 3 2
  604. 4 3
  605. 5 3
  606. 6 2
  607. 7 2
  608. DROP TABLE t1;
  609. # Test with another column before
  610. CREATE TABLE t1 (
  611. c1 INT,
  612. c2 INT NOT NULL AUTO_INCREMENT,
  613. PRIMARY KEY (c2))
  614. ENGINE = 'InnoDB'
  615. PARTITION BY HASH(c2)
  616. PARTITIONS 2;
  617. INSERT INTO t1 VALUES (1, 0);
  618. INSERT INTO t1 VALUES (1, 1);
  619. INSERT INTO t1 VALUES (1, NULL);
  620. INSERT INTO t1 VALUES (2, NULL), (3, 11), (3, NULL), (2, 0);
  621. INSERT INTO t1 VALUES (2, NULL);
  622. INSERT INTO t1 VALUES (2, 2);
  623. INSERT INTO t1 VALUES (2, 22);
  624. INSERT INTO t1 VALUES (2, NULL);
  625. SELECT * FROM t1 ORDER BY c1,c2;
  626. c1 c2
  627. 1 1
  628. 1 2
  629. 2 3
  630. 2 13
  631. 2 14
  632. 2 22
  633. 2 23
  634. 3 11
  635. 3 12
  636. DROP TABLE t1;
  637. # Test with auto_increment on secondary column in multi-column-index
  638. CREATE TABLE t1 (
  639. c1 INT,
  640. c2 INT NOT NULL AUTO_INCREMENT,
  641. PRIMARY KEY (c1,c2))
  642. ENGINE = 'InnoDB'
  643. PARTITION BY HASH(c2)
  644. PARTITIONS 2;
  645. ERROR 42000: Incorrect table definition; there can be only one auto column and it must be defined as a key
  646. # Test AUTO_INCREMENT in CREATE
  647. CREATE TABLE t1 (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (c1))
  648. ENGINE = 'InnoDB'
  649. AUTO_INCREMENT = 15
  650. PARTITION BY HASH(c1)
  651. PARTITIONS 2;
  652. SHOW CREATE TABLE t1;
  653. Table Create Table
  654. t1 CREATE TABLE `t1` (
  655. `c1` int(11) NOT NULL AUTO_INCREMENT,
  656. PRIMARY KEY (`c1`)
  657. ) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=latin1
  658. /*!50100 PARTITION BY HASH (c1)
  659. PARTITIONS 2 */
  660. INSERT INTO t1 (c1) VALUES (4);
  661. SHOW CREATE TABLE t1;
  662. Table Create Table
  663. t1 CREATE TABLE `t1` (
  664. `c1` int(11) NOT NULL AUTO_INCREMENT,
  665. PRIMARY KEY (`c1`)
  666. ) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=latin1
  667. /*!50100 PARTITION BY HASH (c1)
  668. PARTITIONS 2 */
  669. INSERT INTO t1 (c1) VALUES (0);
  670. SHOW CREATE TABLE t1;
  671. Table Create Table
  672. t1 CREATE TABLE `t1` (
  673. `c1` int(11) NOT NULL AUTO_INCREMENT,
  674. PRIMARY KEY (`c1`)
  675. ) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=latin1
  676. /*!50100 PARTITION BY HASH (c1)
  677. PARTITIONS 2 */
  678. INSERT INTO t1 (c1) VALUES (NULL);
  679. SHOW CREATE TABLE t1;
  680. Table Create Table
  681. t1 CREATE TABLE `t1` (
  682. `c1` int(11) NOT NULL AUTO_INCREMENT,
  683. PRIMARY KEY (`c1`)
  684. ) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=latin1
  685. /*!50100 PARTITION BY HASH (c1)
  686. PARTITIONS 2 */
  687. SELECT * FROM t1 ORDER BY c1;
  688. c1
  689. 4
  690. 15
  691. 16
  692. # Test sql_mode 'NO_AUTO_VALUE_ON_ZERO'
  693. SET @@session.sql_mode = 'NO_AUTO_VALUE_ON_ZERO';
  694. INSERT INTO t1 (c1) VALUES (300);
  695. SHOW CREATE TABLE t1;
  696. Table Create Table
  697. t1 CREATE TABLE `t1` (
  698. `c1` int(11) NOT NULL AUTO_INCREMENT,
  699. PRIMARY KEY (`c1`)
  700. ) ENGINE=InnoDB AUTO_INCREMENT=301 DEFAULT CHARSET=latin1
  701. /*!50100 PARTITION BY HASH (c1)
  702. PARTITIONS 2 */
  703. INSERT INTO t1 (c1) VALUES (0);
  704. SHOW CREATE TABLE t1;
  705. Table Create Table
  706. t1 CREATE TABLE `t1` (
  707. `c1` int(11) NOT NULL AUTO_INCREMENT,
  708. PRIMARY KEY (`c1`)
  709. ) ENGINE=InnoDB AUTO_INCREMENT=301 DEFAULT CHARSET=latin1
  710. /*!50100 PARTITION BY HASH (c1)
  711. PARTITIONS 2 */
  712. INSERT INTO t1 (c1) VALUES (NULL);
  713. SHOW CREATE TABLE t1;
  714. Table Create Table
  715. t1 CREATE TABLE `t1` (
  716. `c1` int(11) NOT NULL AUTO_INCREMENT,
  717. PRIMARY KEY (`c1`)
  718. ) ENGINE=InnoDB AUTO_INCREMENT=302 DEFAULT CHARSET=latin1
  719. /*!50100 PARTITION BY HASH (c1)
  720. PARTITIONS 2 */
  721. SELECT * FROM t1 ORDER BY c1;
  722. c1
  723. 0
  724. 4
  725. 15
  726. 16
  727. 300
  728. 301
  729. SET @@session.sql_mode = '';
  730. DROP TABLE t1;
  731. # Test SET INSERT_ID
  732. CREATE TABLE t1 (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (c1))
  733. ENGINE = 'InnoDB'
  734. PARTITION BY HASH(c1)
  735. PARTITIONS 2;
  736. SHOW CREATE TABLE t1;
  737. Table Create Table
  738. t1 CREATE TABLE `t1` (
  739. `c1` int(11) NOT NULL AUTO_INCREMENT,
  740. PRIMARY KEY (`c1`)
  741. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  742. /*!50100 PARTITION BY HASH (c1)
  743. PARTITIONS 2 */
  744. INSERT INTO t1 (c1) VALUES (NULL);
  745. SHOW CREATE TABLE t1;
  746. Table Create Table
  747. t1 CREATE TABLE `t1` (
  748. `c1` int(11) NOT NULL AUTO_INCREMENT,
  749. PRIMARY KEY (`c1`)
  750. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  751. /*!50100 PARTITION BY HASH (c1)
  752. PARTITIONS 2 */
  753. SELECT * FROM t1;
  754. c1
  755. 1
  756. SET INSERT_ID = 23;
  757. SHOW CREATE TABLE t1;
  758. Table Create Table
  759. t1 CREATE TABLE `t1` (
  760. `c1` int(11) NOT NULL AUTO_INCREMENT,
  761. PRIMARY KEY (`c1`)
  762. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  763. /*!50100 PARTITION BY HASH (c1)
  764. PARTITIONS 2 */
  765. INSERT INTO t1 (c1) VALUES (NULL);
  766. SHOW CREATE TABLE t1;
  767. Table Create Table
  768. t1 CREATE TABLE `t1` (
  769. `c1` int(11) NOT NULL AUTO_INCREMENT,
  770. PRIMARY KEY (`c1`)
  771. ) ENGINE=InnoDB AUTO_INCREMENT=24 DEFAULT CHARSET=latin1
  772. /*!50100 PARTITION BY HASH (c1)
  773. PARTITIONS 2 */
  774. SELECT * FROM t1 ORDER BY c1;
  775. c1
  776. 1
  777. 23
  778. DROP TABLE t1;
  779. # Testing with FLUSH TABLE
  780. CREATE TABLE t1 (
  781. c1 INT NOT NULL AUTO_INCREMENT,
  782. PRIMARY KEY (c1))
  783. ENGINE='InnoDB'
  784. PARTITION BY HASH(c1)
  785. PARTITIONS 2;
  786. SHOW CREATE TABLE t1;
  787. Table Create Table
  788. t1 CREATE TABLE `t1` (
  789. `c1` int(11) NOT NULL AUTO_INCREMENT,
  790. PRIMARY KEY (`c1`)
  791. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  792. /*!50100 PARTITION BY HASH (c1)
  793. PARTITIONS 2 */
  794. FLUSH TABLE;
  795. SHOW CREATE TABLE t1;
  796. Table Create Table
  797. t1 CREATE TABLE `t1` (
  798. `c1` int(11) NOT NULL AUTO_INCREMENT,
  799. PRIMARY KEY (`c1`)
  800. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  801. /*!50100 PARTITION BY HASH (c1)
  802. PARTITIONS 2 */
  803. INSERT INTO t1 VALUES (4);
  804. FLUSH TABLE;
  805. SHOW CREATE TABLE t1;
  806. Table Create Table
  807. t1 CREATE TABLE `t1` (
  808. `c1` int(11) NOT NULL AUTO_INCREMENT,
  809. PRIMARY KEY (`c1`)
  810. ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1
  811. /*!50100 PARTITION BY HASH (c1)
  812. PARTITIONS 2 */
  813. INSERT INTO t1 VALUES (NULL);
  814. FLUSH TABLE;
  815. SHOW CREATE TABLE t1;
  816. Table Create Table
  817. t1 CREATE TABLE `t1` (
  818. `c1` int(11) NOT NULL AUTO_INCREMENT,
  819. PRIMARY KEY (`c1`)
  820. ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=latin1
  821. /*!50100 PARTITION BY HASH (c1)
  822. PARTITIONS 2 */
  823. SELECT * FROM t1 ORDER BY c1;
  824. c1
  825. 4
  826. 5
  827. DROP TABLE t1;