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.

1026 lines
22 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
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
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. SET INSERT_ID = 29;
  37. INSERT INTO t1 VALUES (NULL), (NULL), (NULL);
  38. INSERT INTO t1 VALUES (NULL);
  39. UPDATE t1 SET c1 = 50 WHERE c1 = 17;
  40. UPDATE t1 SET c1 = 51 WHERE c1 = 19;
  41. FLUSH TABLES;
  42. UPDATE t1 SET c1 = 40 WHERE c1 = 50;
  43. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  44. AND TABLE_NAME='t1';
  45. AUTO_INCREMENT
  46. 32
  47. UPDATE t1 SET c1 = NULL WHERE c1 = 4;
  48. Warnings:
  49. Warning 1048 Column 'c1' cannot be null
  50. INSERT INTO t1 VALUES (NULL);
  51. INSERT INTO t1 VALUES (NULL);
  52. SELECT * FROM t1 ORDER BY c1;
  53. c1
  54. 0
  55. 2
  56. 5
  57. 6
  58. 10
  59. 20
  60. 22
  61. 23
  62. 25
  63. 30
  64. 31
  65. 32
  66. 33
  67. 40
  68. 51
  69. DROP TABLE t1;
  70. CREATE TABLE t1 (
  71. c1 INT NOT NULL AUTO_INCREMENT,
  72. PRIMARY KEY (c1))
  73. ENGINE='InnoDB';
  74. SHOW CREATE TABLE t1;
  75. Table Create Table
  76. t1 CREATE TABLE `t1` (
  77. `c1` int(11) NOT NULL AUTO_INCREMENT,
  78. PRIMARY KEY (`c1`)
  79. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  80. FLUSH TABLE;
  81. SHOW CREATE TABLE t1;
  82. Table Create Table
  83. t1 CREATE TABLE `t1` (
  84. `c1` int(11) NOT NULL AUTO_INCREMENT,
  85. PRIMARY KEY (`c1`)
  86. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  87. INSERT INTO t1 VALUES (4);
  88. FLUSH TABLE;
  89. SHOW CREATE TABLE t1;
  90. Table Create Table
  91. t1 CREATE TABLE `t1` (
  92. `c1` int(11) NOT NULL AUTO_INCREMENT,
  93. PRIMARY KEY (`c1`)
  94. ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1
  95. INSERT INTO t1 VALUES (NULL);
  96. FLUSH TABLE;
  97. SHOW CREATE TABLE t1;
  98. Table Create Table
  99. t1 CREATE TABLE `t1` (
  100. `c1` int(11) NOT NULL AUTO_INCREMENT,
  101. PRIMARY KEY (`c1`)
  102. ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=latin1
  103. DELETE FROM t1;
  104. INSERT INTO t1 VALUES (NULL);
  105. SHOW CREATE TABLE t1;
  106. Table Create Table
  107. t1 CREATE TABLE `t1` (
  108. `c1` int(11) NOT NULL AUTO_INCREMENT,
  109. PRIMARY KEY (`c1`)
  110. ) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=latin1
  111. SELECT * FROM t1 ORDER BY c1;
  112. c1
  113. 6
  114. TRUNCATE TABLE t1;
  115. INSERT INTO t1 VALUES (NULL);
  116. SHOW CREATE TABLE t1;
  117. Table Create Table
  118. t1 CREATE TABLE `t1` (
  119. `c1` int(11) NOT NULL AUTO_INCREMENT,
  120. PRIMARY KEY (`c1`)
  121. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  122. SELECT * FROM t1 ORDER BY c1;
  123. c1
  124. 1
  125. INSERT INTO t1 VALUES (100);
  126. INSERT INTO t1 VALUES (NULL);
  127. DELETE FROM t1 WHERE c1 >= 100;
  128. OPTIMIZE TABLE t1;
  129. Table Op Msg_type Msg_text
  130. test.t1 optimize note Table does not support optimize, doing recreate + analyze instead
  131. test.t1 optimize status OK
  132. SHOW CREATE TABLE t1;
  133. Table Create Table
  134. t1 CREATE TABLE `t1` (
  135. `c1` int(11) NOT NULL AUTO_INCREMENT,
  136. PRIMARY KEY (`c1`)
  137. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  138. DROP TABLE t1;
  139. # Simple test with NULL
  140. CREATE TABLE t1 (
  141. c1 INT NOT NULL AUTO_INCREMENT,
  142. PRIMARY KEY (c1))
  143. ENGINE='InnoDB'
  144. PARTITION BY HASH(c1)
  145. PARTITIONS 2;
  146. INSERT INTO t1 VALUES (NULL);
  147. SHOW CREATE TABLE t1;
  148. Table Create Table
  149. t1 CREATE TABLE `t1` (
  150. `c1` int(11) NOT NULL AUTO_INCREMENT,
  151. PRIMARY KEY (`c1`)
  152. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  153. /*!50100 PARTITION BY HASH (c1)
  154. PARTITIONS 2 */
  155. SELECT * FROM t1;
  156. c1
  157. 1
  158. DROP TABLE t1;
  159. # Test with sql_mode and first insert as 0
  160. CREATE TABLE t1 (
  161. c1 INT,
  162. c2 INT NOT NULL AUTO_INCREMENT,
  163. PRIMARY KEY (c2))
  164. ENGINE='InnoDB'
  165. PARTITION BY HASH(c2)
  166. PARTITIONS 2;
  167. INSERT INTO t1 VALUES (1, NULL);
  168. INSERT INTO t1 VALUES (1, 1), (99, 99);
  169. INSERT INTO t1 VALUES (1, NULL);
  170. SET @@session.sql_mode = 'NO_AUTO_VALUE_ON_ZERO';
  171. INSERT INTO t1 VALUES (1, 0);
  172. SELECT * FROM t1 ORDER BY c1, c2;
  173. c1 c2
  174. 1 0
  175. 1 1
  176. 1 2
  177. DROP TABLE t1;
  178. CREATE TABLE t1 (
  179. c1 INT,
  180. c2 INT NOT NULL AUTO_INCREMENT,
  181. PRIMARY KEY (c2))
  182. ENGINE='InnoDB'
  183. PARTITION BY HASH(c2)
  184. PARTITIONS 2;
  185. INSERT INTO t1 VALUES (1, 0);
  186. INSERT INTO t1 VALUES (1, 1), (1, NULL);
  187. INSERT INTO t1 VALUES (2, NULL), (4, 7);
  188. INSERT INTO t1 VALUES (1, NULL);
  189. SELECT * FROM t1 ORDER BY c1, c2;
  190. c1 c2
  191. 1 0
  192. 1 1
  193. 1 2
  194. 1 8
  195. 2 3
  196. 4 7
  197. SET @@session.sql_mode = '';
  198. DROP TABLE t1;
  199. # Simple test with NULL, 0 and explicit values both incr. and desc.
  200. CREATE TABLE t1 (
  201. c1 INT NOT NULL AUTO_INCREMENT,
  202. PRIMARY KEY (c1))
  203. ENGINE='InnoDB'
  204. PARTITION BY HASH(c1)
  205. PARTITIONS 2;
  206. INSERT INTO t1 VALUES (2), (4), (NULL);
  207. INSERT INTO t1 VALUES (0);
  208. INSERT INTO t1 VALUES (5), (16);
  209. INSERT INTO t1 VALUES (17), (19), (NULL);
  210. INSERT INTO t1 VALUES (NULL), (10), (NULL);
  211. INSERT INTO t1 VALUES (NULL), (9);
  212. INSERT INTO t1 VALUES (59), (55);
  213. INSERT INTO t1 VALUES (NULL), (90);
  214. INSERT INTO t1 VALUES (NULL);
  215. UPDATE t1 SET c1 = 150 WHERE c1 = 17;
  216. UPDATE t1 SET c1 = 151 WHERE c1 = 19;
  217. FLUSH TABLES;
  218. UPDATE t1 SET c1 = 140 WHERE c1 = 150;
  219. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  220. AND TABLE_NAME='t1';
  221. AUTO_INCREMENT
  222. 141
  223. UPDATE t1 SET c1 = NULL WHERE c1 = 4;
  224. Warnings:
  225. Warning 1048 Column 'c1' cannot be null
  226. INSERT INTO t1 VALUES (NULL);
  227. INSERT INTO t1 VALUES (NULL);
  228. SELECT * FROM t1 ORDER BY c1;
  229. c1
  230. 0
  231. 2
  232. 5
  233. 6
  234. 9
  235. 10
  236. 20
  237. 21
  238. 22
  239. 23
  240. 55
  241. 59
  242. 60
  243. 90
  244. 91
  245. 140
  246. 141
  247. 142
  248. 151
  249. DROP TABLE t1;
  250. # Test with auto_increment_increment and auto_increment_offset.
  251. CREATE TABLE t1 (
  252. c1 INT NOT NULL AUTO_INCREMENT,
  253. PRIMARY KEY (c1))
  254. ENGINE='InnoDB'
  255. PARTITION BY HASH(c1)
  256. PARTITIONS 2;
  257. SET @@session.auto_increment_increment = 10;
  258. SET @@session.auto_increment_offset = 5;
  259. INSERT INTO t1 VALUES (1);
  260. INSERT INTO t1 VALUES (NULL), (NULL), (NULL);
  261. SET @@session.auto_increment_increment = 5;
  262. SET @@session.auto_increment_offset = 3;
  263. INSERT INTO t1 VALUES (NULL);
  264. INSERT INTO t1 VALUES (33 + 1);
  265. INSERT INTO t1 VALUES (NULL);
  266. INSERT INTO t1 VALUES (38 + 2);
  267. INSERT INTO t1 VALUES (NULL);
  268. INSERT INTO t1 VALUES (43 + 3);
  269. INSERT INTO t1 VALUES (NULL);
  270. INSERT INTO t1 VALUES (48 + 4);
  271. INSERT INTO t1 VALUES (NULL);
  272. INSERT INTO t1 VALUES (53 + 5);
  273. INSERT INTO t1 VALUES (NULL);
  274. INSERT INTO t1 VALUES (63 + 6);
  275. INSERT INTO t1 VALUES (NULL);
  276. SET @@session.auto_increment_increment = 1;
  277. SET @@session.auto_increment_offset = 1;
  278. SELECT * FROM t1 ORDER BY c1;
  279. c1
  280. 1
  281. 5
  282. 15
  283. 25
  284. 33
  285. 34
  286. 38
  287. 40
  288. 43
  289. 46
  290. 48
  291. 52
  292. 53
  293. 58
  294. 63
  295. 69
  296. 73
  297. DROP TABLE t1;
  298. # Test reported auto_increment value
  299. CREATE TABLE t1 (
  300. c1 INT NOT NULL AUTO_INCREMENT,
  301. PRIMARY KEY (c1))
  302. ENGINE='InnoDB'
  303. PARTITION BY HASH (c1)
  304. PARTITIONS 2;
  305. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  306. AND TABLE_NAME='t1';
  307. AUTO_INCREMENT
  308. 1
  309. INSERT INTO t1 VALUES (2);
  310. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  311. AND TABLE_NAME='t1';
  312. AUTO_INCREMENT
  313. 3
  314. INSERT INTO t1 VALUES (4);
  315. INSERT INTO t1 VALUES (NULL);
  316. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  317. AND TABLE_NAME='t1';
  318. AUTO_INCREMENT
  319. 6
  320. INSERT INTO t1 VALUES (NULL);
  321. INSERT INTO t1 VALUES (17);
  322. INSERT INTO t1 VALUES (19);
  323. INSERT INTO t1 VALUES (NULL);
  324. INSERT INTO t1 VALUES (NULL);
  325. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  326. AND TABLE_NAME='t1';
  327. AUTO_INCREMENT
  328. 22
  329. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  330. AND TABLE_NAME='t1';
  331. AUTO_INCREMENT
  332. 22
  333. INSERT INTO t1 VALUES (10);
  334. SELECT * FROM t1 ORDER BY c1;
  335. c1
  336. 2
  337. 4
  338. 5
  339. 6
  340. 10
  341. 17
  342. 19
  343. 20
  344. 21
  345. INSERT INTO t1 VALUES (NULL);
  346. SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test'
  347. AND TABLE_NAME='t1';
  348. AUTO_INCREMENT
  349. 23
  350. INSERT INTO t1 VALUES (NULL);
  351. INSERT INTO t1 VALUES (15);
  352. INSERT INTO t1 VALUES (NULL);
  353. SELECT * FROM t1 ORDER BY c1;
  354. c1
  355. 2
  356. 4
  357. 5
  358. 6
  359. 10
  360. 15
  361. 17
  362. 19
  363. 20
  364. 21
  365. 22
  366. 23
  367. 24
  368. INSERT INTO t1 VALUES (NULL);
  369. DELETE FROM t1;
  370. INSERT INTO t1 VALUES (NULL);
  371. SHOW CREATE TABLE t1;
  372. Table Create Table
  373. t1 CREATE TABLE `t1` (
  374. `c1` int(11) NOT NULL AUTO_INCREMENT,
  375. PRIMARY KEY (`c1`)
  376. ) ENGINE=InnoDB AUTO_INCREMENT=27 DEFAULT CHARSET=latin1
  377. /*!50100 PARTITION BY HASH (c1)
  378. PARTITIONS 2 */
  379. SELECT * FROM t1 ORDER BY c1;
  380. c1
  381. 26
  382. TRUNCATE TABLE t1;
  383. INSERT INTO t1 VALUES (NULL);
  384. SHOW CREATE TABLE t1;
  385. Table Create Table
  386. t1 CREATE TABLE `t1` (
  387. `c1` int(11) NOT NULL AUTO_INCREMENT,
  388. PRIMARY KEY (`c1`)
  389. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  390. /*!50100 PARTITION BY HASH (c1)
  391. PARTITIONS 2 */
  392. SELECT * FROM t1 ORDER BY c1;
  393. c1
  394. 1
  395. INSERT INTO t1 VALUES (100);
  396. INSERT INTO t1 VALUES (NULL);
  397. DELETE FROM t1 WHERE c1 >= 100;
  398. OPTIMIZE TABLE t1;
  399. Table Op Msg_type Msg_text
  400. test.t1 optimize note Table does not support optimize, doing recreate + analyze instead
  401. test.t1 optimize status OK
  402. SHOW CREATE TABLE t1;
  403. Table Create Table
  404. t1 CREATE TABLE `t1` (
  405. `c1` int(11) NOT NULL AUTO_INCREMENT,
  406. PRIMARY KEY (`c1`)
  407. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  408. /*!50100 PARTITION BY HASH (c1)
  409. PARTITIONS 2 */
  410. DROP TABLE t1;
  411. # Test with two threads
  412. # con default
  413. CREATE TABLE t1 (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (c1))
  414. ENGINE = 'InnoDB'
  415. PARTITION BY HASH(c1)
  416. PARTITIONS 2;
  417. INSERT INTO t1 (c1) VALUES (2);
  418. INSERT INTO t1 (c1) VALUES (4);
  419. # con1
  420. INSERT INTO t1 (c1) VALUES (NULL);
  421. INSERT INTO t1 (c1) VALUES (10);
  422. # con default
  423. INSERT INTO t1 (c1) VALUES (NULL);
  424. INSERT INTO t1 (c1) VALUES (NULL);
  425. INSERT INTO t1 (c1) VALUES (19);
  426. INSERT INTO t1 (c1) VALUES (21);
  427. # con1
  428. INSERT INTO t1 (c1) VALUES (NULL);
  429. # con default
  430. INSERT INTO t1 (c1) VALUES (16);
  431. # con1
  432. INSERT INTO t1 (c1) VALUES (NULL);
  433. # con default
  434. INSERT INTO t1 (c1) VALUES (NULL);
  435. SELECT * FROM t1 ORDER BY c1;
  436. c1
  437. 2
  438. 4
  439. 5
  440. 10
  441. 11
  442. 12
  443. 16
  444. 19
  445. 21
  446. 22
  447. 23
  448. 24
  449. DROP TABLE t1;
  450. # Test with two threads + start transaction NO PARTITIONING
  451. # con default
  452. CREATE TABLE t1 (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (c1))
  453. ENGINE = 'InnoDB';
  454. START TRANSACTION;
  455. INSERT INTO t1 (c1) VALUES (2);
  456. INSERT INTO t1 (c1) VALUES (4);
  457. # con1
  458. START TRANSACTION;
  459. INSERT INTO t1 (c1) VALUES (NULL);
  460. INSERT INTO t1 (c1) VALUES (10);
  461. # con default
  462. INSERT INTO t1 (c1) VALUES (NULL);
  463. INSERT INTO t1 (c1) VALUES (NULL);
  464. INSERT INTO t1 (c1) VALUES (19);
  465. INSERT INTO t1 (c1) VALUES (21);
  466. # con1
  467. INSERT INTO t1 (c1) VALUES (NULL);
  468. # con default
  469. INSERT INTO t1 (c1) VALUES (16);
  470. # con1
  471. INSERT INTO t1 (c1) VALUES (NULL);
  472. SELECT * FROM t1 ORDER BY c1;
  473. c1
  474. 5
  475. 10
  476. 22
  477. 23
  478. COMMIT;
  479. SELECT * FROM t1 ORDER BY c1;
  480. c1
  481. 5
  482. 10
  483. 22
  484. 23
  485. # con default
  486. INSERT INTO t1 (c1) VALUES (NULL);
  487. SELECT * FROM t1 ORDER BY c1;
  488. c1
  489. 2
  490. 4
  491. 5
  492. 10
  493. 11
  494. 12
  495. 16
  496. 19
  497. 21
  498. 22
  499. 23
  500. 24
  501. COMMIT;
  502. SELECT * FROM t1 ORDER BY c1;
  503. c1
  504. 2
  505. 4
  506. 5
  507. 10
  508. 11
  509. 12
  510. 16
  511. 19
  512. 21
  513. 22
  514. 23
  515. 24
  516. DROP TABLE t1;
  517. # Test with two threads + start transaction
  518. # con default
  519. CREATE TABLE t1 (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (c1))
  520. ENGINE = 'InnoDB'
  521. PARTITION BY HASH(c1)
  522. PARTITIONS 2;
  523. START TRANSACTION;
  524. INSERT INTO t1 (c1) VALUES (2);
  525. INSERT INTO t1 (c1) VALUES (4);
  526. # con1
  527. START TRANSACTION;
  528. INSERT INTO t1 (c1) VALUES (NULL), (10);
  529. # con default
  530. INSERT INTO t1 (c1) VALUES (NULL), (NULL), (19);
  531. INSERT INTO t1 (c1) VALUES (21);
  532. # con1
  533. INSERT INTO t1 (c1) VALUES (NULL);
  534. # con default
  535. INSERT INTO t1 (c1) VALUES (16);
  536. # con1
  537. INSERT INTO t1 (c1) VALUES (NULL);
  538. SELECT * FROM t1 ORDER BY c1;
  539. c1
  540. 5
  541. 10
  542. 22
  543. 23
  544. COMMIT;
  545. SELECT * FROM t1 ORDER BY c1;
  546. c1
  547. 5
  548. 10
  549. 22
  550. 23
  551. # con default
  552. INSERT INTO t1 (c1) VALUES (NULL);
  553. SELECT * FROM t1 ORDER BY c1;
  554. c1
  555. 2
  556. 4
  557. 5
  558. 10
  559. 11
  560. 12
  561. 16
  562. 19
  563. 21
  564. 22
  565. 23
  566. 24
  567. COMMIT;
  568. SELECT * FROM t1 ORDER BY c1;
  569. c1
  570. 2
  571. 4
  572. 5
  573. 10
  574. 11
  575. 12
  576. 16
  577. 19
  578. 21
  579. 22
  580. 23
  581. 24
  582. DROP TABLE t1;
  583. # Test with another column after
  584. CREATE TABLE t1 (
  585. c1 INT NOT NULL AUTO_INCREMENT,
  586. c2 INT,
  587. PRIMARY KEY (c1,c2))
  588. ENGINE = 'InnoDB'
  589. PARTITION BY HASH(c2)
  590. PARTITIONS 2;
  591. INSERT INTO t1 VALUES (1, 0);
  592. INSERT INTO t1 VALUES (1, 1);
  593. INSERT INTO t1 VALUES (NULL, 1), (NULL, 2), (NULL, 3);
  594. INSERT INTO t1 VALUES (NULL, 3);
  595. INSERT INTO t1 VALUES (2, 0), (NULL, 2);
  596. INSERT INTO t1 VALUES (2, 2);
  597. INSERT INTO t1 VALUES (2, 22);
  598. INSERT INTO t1 VALUES (NULL, 2);
  599. SELECT * FROM t1 ORDER BY c1,c2;
  600. c1 c2
  601. 1 0
  602. 1 1
  603. 2 0
  604. 2 1
  605. 2 2
  606. 2 22
  607. 3 2
  608. 4 3
  609. 5 3
  610. 6 2
  611. 7 2
  612. DROP TABLE t1;
  613. # Test with another column before
  614. CREATE TABLE t1 (
  615. c1 INT,
  616. c2 INT NOT NULL AUTO_INCREMENT,
  617. PRIMARY KEY (c2))
  618. ENGINE = 'InnoDB'
  619. PARTITION BY HASH(c2)
  620. PARTITIONS 2;
  621. INSERT INTO t1 VALUES (1, 0);
  622. INSERT INTO t1 VALUES (1, 1);
  623. INSERT INTO t1 VALUES (1, NULL);
  624. INSERT INTO t1 VALUES (2, NULL), (3, 11), (3, NULL), (2, 0);
  625. INSERT INTO t1 VALUES (2, NULL);
  626. INSERT INTO t1 VALUES (2, 2);
  627. INSERT INTO t1 VALUES (2, 22);
  628. INSERT INTO t1 VALUES (2, NULL);
  629. SELECT * FROM t1 ORDER BY c1,c2;
  630. c1 c2
  631. 1 1
  632. 1 2
  633. 2 3
  634. 2 13
  635. 2 14
  636. 2 22
  637. 2 23
  638. 3 11
  639. 3 12
  640. DROP TABLE t1;
  641. # Test with auto_increment on secondary column in multi-column-index
  642. CREATE TABLE t1 (
  643. c1 INT,
  644. c2 INT NOT NULL AUTO_INCREMENT,
  645. PRIMARY KEY (c1,c2))
  646. ENGINE = 'InnoDB'
  647. PARTITION BY HASH(c2)
  648. PARTITIONS 2;
  649. ERROR 42000: Incorrect table definition; there can be only one auto column and it must be defined as a key
  650. # Test AUTO_INCREMENT in CREATE
  651. CREATE TABLE t1 (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (c1))
  652. ENGINE = 'InnoDB'
  653. AUTO_INCREMENT = 15
  654. PARTITION BY HASH(c1)
  655. PARTITIONS 2;
  656. SHOW CREATE TABLE t1;
  657. Table Create Table
  658. t1 CREATE TABLE `t1` (
  659. `c1` int(11) NOT NULL AUTO_INCREMENT,
  660. PRIMARY KEY (`c1`)
  661. ) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=latin1
  662. /*!50100 PARTITION BY HASH (c1)
  663. PARTITIONS 2 */
  664. INSERT INTO t1 (c1) VALUES (4);
  665. SHOW CREATE TABLE t1;
  666. Table Create Table
  667. t1 CREATE TABLE `t1` (
  668. `c1` int(11) NOT NULL AUTO_INCREMENT,
  669. PRIMARY KEY (`c1`)
  670. ) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=latin1
  671. /*!50100 PARTITION BY HASH (c1)
  672. PARTITIONS 2 */
  673. INSERT INTO t1 (c1) VALUES (0);
  674. SHOW CREATE TABLE t1;
  675. Table Create Table
  676. t1 CREATE TABLE `t1` (
  677. `c1` int(11) NOT NULL AUTO_INCREMENT,
  678. PRIMARY KEY (`c1`)
  679. ) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=latin1
  680. /*!50100 PARTITION BY HASH (c1)
  681. PARTITIONS 2 */
  682. INSERT INTO t1 (c1) VALUES (NULL);
  683. SHOW CREATE TABLE t1;
  684. Table Create Table
  685. t1 CREATE TABLE `t1` (
  686. `c1` int(11) NOT NULL AUTO_INCREMENT,
  687. PRIMARY KEY (`c1`)
  688. ) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=latin1
  689. /*!50100 PARTITION BY HASH (c1)
  690. PARTITIONS 2 */
  691. SELECT * FROM t1 ORDER BY c1;
  692. c1
  693. 4
  694. 15
  695. 16
  696. # Test sql_mode 'NO_AUTO_VALUE_ON_ZERO'
  697. SET @@session.sql_mode = 'NO_AUTO_VALUE_ON_ZERO';
  698. INSERT INTO t1 (c1) VALUES (300);
  699. SHOW CREATE TABLE t1;
  700. Table Create Table
  701. t1 CREATE TABLE `t1` (
  702. `c1` int(11) NOT NULL AUTO_INCREMENT,
  703. PRIMARY KEY (`c1`)
  704. ) ENGINE=InnoDB AUTO_INCREMENT=301 DEFAULT CHARSET=latin1
  705. /*!50100 PARTITION BY HASH (c1)
  706. PARTITIONS 2 */
  707. INSERT INTO t1 (c1) VALUES (0);
  708. SHOW CREATE TABLE t1;
  709. Table Create Table
  710. t1 CREATE TABLE `t1` (
  711. `c1` int(11) NOT NULL AUTO_INCREMENT,
  712. PRIMARY KEY (`c1`)
  713. ) ENGINE=InnoDB AUTO_INCREMENT=301 DEFAULT CHARSET=latin1
  714. /*!50100 PARTITION BY HASH (c1)
  715. PARTITIONS 2 */
  716. INSERT INTO t1 (c1) VALUES (NULL);
  717. SHOW CREATE TABLE t1;
  718. Table Create Table
  719. t1 CREATE TABLE `t1` (
  720. `c1` int(11) NOT NULL AUTO_INCREMENT,
  721. PRIMARY KEY (`c1`)
  722. ) ENGINE=InnoDB AUTO_INCREMENT=302 DEFAULT CHARSET=latin1
  723. /*!50100 PARTITION BY HASH (c1)
  724. PARTITIONS 2 */
  725. SELECT * FROM t1 ORDER BY c1;
  726. c1
  727. 0
  728. 4
  729. 15
  730. 16
  731. 300
  732. 301
  733. SET @@session.sql_mode = '';
  734. DROP TABLE t1;
  735. # Test SET INSERT_ID
  736. CREATE TABLE t1 (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (c1))
  737. ENGINE = 'InnoDB'
  738. PARTITION BY HASH(c1)
  739. PARTITIONS 2;
  740. SHOW CREATE TABLE t1;
  741. Table Create Table
  742. t1 CREATE TABLE `t1` (
  743. `c1` int(11) NOT NULL AUTO_INCREMENT,
  744. PRIMARY KEY (`c1`)
  745. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  746. /*!50100 PARTITION BY HASH (c1)
  747. PARTITIONS 2 */
  748. INSERT INTO t1 (c1) VALUES (NULL);
  749. SHOW CREATE TABLE t1;
  750. Table Create Table
  751. t1 CREATE TABLE `t1` (
  752. `c1` int(11) NOT NULL AUTO_INCREMENT,
  753. PRIMARY KEY (`c1`)
  754. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  755. /*!50100 PARTITION BY HASH (c1)
  756. PARTITIONS 2 */
  757. SELECT * FROM t1;
  758. c1
  759. 1
  760. SET INSERT_ID = 23;
  761. SHOW CREATE TABLE t1;
  762. Table Create Table
  763. t1 CREATE TABLE `t1` (
  764. `c1` int(11) NOT NULL AUTO_INCREMENT,
  765. PRIMARY KEY (`c1`)
  766. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
  767. /*!50100 PARTITION BY HASH (c1)
  768. PARTITIONS 2 */
  769. INSERT INTO t1 (c1) VALUES (NULL);
  770. SHOW CREATE TABLE t1;
  771. Table Create Table
  772. t1 CREATE TABLE `t1` (
  773. `c1` int(11) NOT NULL AUTO_INCREMENT,
  774. PRIMARY KEY (`c1`)
  775. ) ENGINE=InnoDB AUTO_INCREMENT=24 DEFAULT CHARSET=latin1
  776. /*!50100 PARTITION BY HASH (c1)
  777. PARTITIONS 2 */
  778. SET INSERT_ID = 22;
  779. INSERT INTO t1 VALUES (NULL), (NULL), (NULL);
  780. INSERT INTO t1 VALUES (NULL);
  781. SELECT * FROM t1 ORDER BY c1;
  782. c1
  783. 1
  784. 23
  785. 24
  786. DROP TABLE t1;
  787. # Testing with FLUSH TABLE
  788. CREATE TABLE t1 (
  789. c1 INT NOT NULL AUTO_INCREMENT,
  790. PRIMARY KEY (c1))
  791. ENGINE='InnoDB'
  792. PARTITION BY HASH(c1)
  793. PARTITIONS 2;
  794. SHOW CREATE TABLE t1;
  795. Table Create Table
  796. t1 CREATE TABLE `t1` (
  797. `c1` int(11) NOT NULL AUTO_INCREMENT,
  798. PRIMARY KEY (`c1`)
  799. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  800. /*!50100 PARTITION BY HASH (c1)
  801. PARTITIONS 2 */
  802. FLUSH TABLE;
  803. SHOW CREATE TABLE t1;
  804. Table Create Table
  805. t1 CREATE TABLE `t1` (
  806. `c1` int(11) NOT NULL AUTO_INCREMENT,
  807. PRIMARY KEY (`c1`)
  808. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  809. /*!50100 PARTITION BY HASH (c1)
  810. PARTITIONS 2 */
  811. INSERT INTO t1 VALUES (4);
  812. FLUSH TABLE;
  813. SHOW CREATE TABLE t1;
  814. Table Create Table
  815. t1 CREATE TABLE `t1` (
  816. `c1` int(11) NOT NULL AUTO_INCREMENT,
  817. PRIMARY KEY (`c1`)
  818. ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1
  819. /*!50100 PARTITION BY HASH (c1)
  820. PARTITIONS 2 */
  821. INSERT INTO t1 VALUES (NULL);
  822. FLUSH TABLE;
  823. SHOW CREATE TABLE t1;
  824. Table Create Table
  825. t1 CREATE TABLE `t1` (
  826. `c1` int(11) NOT NULL AUTO_INCREMENT,
  827. PRIMARY KEY (`c1`)
  828. ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=latin1
  829. /*!50100 PARTITION BY HASH (c1)
  830. PARTITIONS 2 */
  831. SELECT * FROM t1 ORDER BY c1;
  832. c1
  833. 4
  834. 5
  835. DROP TABLE t1;
  836. #############################################################################
  837. # Bug #45823 - Assertion failure in file row/row0mysql.c line 1386
  838. # Bug #43988 - AUTO_INCREMENT errors with partitioned InnoDB tables in 5.1.31
  839. ##############################################################################
  840. # Inserting negative autoincrement values into a partition table (partitions >= 4)
  841. CREATE TABLE t (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(c1),
  842. c2 INT) ENGINE='InnoDB' PARTITION BY HASH(c1) PARTITIONS 4;
  843. INSERT INTO t(c2) VALUES (10);
  844. INSERT INTO t(c2) VALUES (20);
  845. INSERT INTO t VALUES (-1,-10);
  846. INSERT INTO t(c2) VALUES (30);
  847. INSERT INTO t(c2) VALUES (40);
  848. SELECT * FROM t ORDER BY c1 ASC;
  849. c1 c2
  850. -1 -10
  851. 1 10
  852. 2 20
  853. 3 30
  854. 4 40
  855. DROP TABLE t;
  856. # Reading from a partition table (partitions >= 2 ) after inserting a negative
  857. # value into the auto increment column
  858. CREATE TABLE t (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(c1),
  859. c2 INT) ENGINE='InnoDB' PARTITION BY HASH(c1) PARTITIONS 2;
  860. INSERT INTO t VALUES (-2,-20);
  861. INSERT INTO t(c2) VALUES (30);
  862. SELECT * FROM t ORDER BY c1 ASC;
  863. c1 c2
  864. -2 -20
  865. 1 30
  866. DROP TABLE t;
  867. # Inserting negative auto increment value into a partition table (partitions >= 2)
  868. # auto increment value > 2.
  869. CREATE TABLE t (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(c1),
  870. c2 INT) ENGINE='InnoDB' PARTITION BY HASH(c1) PARTITIONS 2;
  871. INSERT INTO t VALUES (-4,-20);
  872. INSERT INTO t(c2) VALUES (30);
  873. INSERT INTO t(c2) VALUES (40);
  874. SELECT * FROM t ORDER BY c1 ASC;
  875. c1 c2
  876. -4 -20
  877. 1 30
  878. 2 40
  879. DROP TABLE t;
  880. # Inserting -1 into autoincrement column of a partition table (partition >= 4)
  881. CREATE TABLE t (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(c1),
  882. c2 INT) ENGINE='InnoDB' PARTITION BY HASH(c1) PARTITIONS 4;
  883. INSERT INTO t(c2) VALUES (10);
  884. INSERT INTO t(c2) VALUES (20);
  885. INSERT INTO t VALUES (-1,-10);
  886. SELECT * FROM t ORDER BY c1 ASC;
  887. c1 c2
  888. -1 -10
  889. 1 10
  890. 2 20
  891. INSERT INTO t(c2) VALUES (30);
  892. SELECT * FROM t ORDER BY c1 ASC;
  893. c1 c2
  894. -1 -10
  895. 1 10
  896. 2 20
  897. 3 30
  898. DROP TABLE t;
  899. # Deleting from an auto increment table after inserting negative values
  900. CREATE TABLE t (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(c1),
  901. c2 INT) ENGINE='InnoDB' PARTITION BY HASH(c1) PARTITIONS 4;
  902. INSERT INTO t(c2) VALUES (10);
  903. INSERT INTO t(c2) VALUES (20);
  904. INSERT INTO t VALUES (-1,-10);
  905. INSERT INTO t(c2) VALUES (30);
  906. INSERT INTO t VALUES (-3,-20);
  907. INSERT INTO t(c2) VALUES (40);
  908. SELECT * FROM t ORDER BY c1 ASC;
  909. c1 c2
  910. -3 -20
  911. -1 -10
  912. 1 10
  913. 2 20
  914. 3 30
  915. 4 40
  916. DELETE FROM t WHERE c1 > 1;
  917. SELECT * FROM t ORDER BY c1 ASC;
  918. c1 c2
  919. -3 -20
  920. -1 -10
  921. 1 10
  922. DROP TABLE t;
  923. # Inserting a positive value that exceeds maximum allowed value for an
  924. # Auto Increment column (positive maximum)
  925. CREATE TABLE t (c1 TINYINT NOT NULL AUTO_INCREMENT, PRIMARY KEY(c1),
  926. c2 INT) ENGINE='InnoDB' PARTITION BY HASH(c1) PARTITIONS 4;
  927. INSERT INTO t(c2) VALUES (10);
  928. INSERT INTO t(c2) VALUES (20);
  929. INSERT INTO t VALUES (126,30);
  930. INSERT INTO t VALUES (127,40);
  931. INSERT INTO t VALUES (128,50);
  932. ERROR 23000: Duplicate entry '127' for key 'PRIMARY'
  933. INSERT INTO t VALUES (129,60);
  934. ERROR 23000: Duplicate entry '127' for key 'PRIMARY'
  935. SELECT * FROM t ORDER BY c1 ASC;
  936. c1 c2
  937. 1 10
  938. 2 20
  939. 126 30
  940. 127 40
  941. DROP TABLE t;
  942. # Inserting a negative value that goes below minimum allowed value for an
  943. # Auto Increment column (negative minimum)
  944. CREATE TABLE t (c1 TINYINT NOT NULL AUTO_INCREMENT, PRIMARY KEY(c1),
  945. c2 INT) ENGINE='InnoDB' PARTITION BY HASH(c1) PARTITIONS 4;
  946. INSERT INTO t(c2) VALUES (10);
  947. INSERT INTO t(c2) VALUES (20);
  948. INSERT INTO t VALUES (-127,30);
  949. INSERT INTO t VALUES (-128,40);
  950. INSERT INTO t VALUES (-129,50);
  951. ERROR 23000: Duplicate entry '-128' for key 'PRIMARY'
  952. INSERT INTO t VALUES (-130,60);
  953. ERROR 23000: Duplicate entry '-128' for key 'PRIMARY'
  954. SELECT * FROM t ORDER BY c1 ASC;
  955. c1 c2
  956. -128 40
  957. -127 30
  958. 1 10
  959. 2 20
  960. DROP TABLE t;
  961. # Updating the partition table with a negative Auto Increment value
  962. CREATE TABLE t (c1 INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(c1),
  963. c2 INT) ENGINE='InnoDB' PARTITION BY HASH(c1) PARTITIONS 4;
  964. INSERT INTO t(c2) VALUES (10);
  965. INSERT INTO t(c2) VALUES (20);
  966. INSERT INTO t VALUES (-1,-10);
  967. INSERT INTO t(c2) VALUES (30);
  968. SELECT * FROM t ORDER BY c1 ASC;
  969. c1 c2
  970. -1 -10
  971. 1 10
  972. 2 20
  973. 3 30
  974. UPDATE t SET c1 = -6 WHERE c1 = 2;
  975. SELECT * FROM t ORDER BY c1 ASC;
  976. c1 c2
  977. -6 20
  978. -1 -10
  979. 1 10
  980. 3 30
  981. INSERT INTO t(c2) VALUES (40);
  982. INSERT INTO t(c2) VALUES (50);
  983. UPDATE t SET c1 = -6 WHERE c1 = 2;
  984. SELECT * FROM t ORDER BY c1 ASC;
  985. c1 c2
  986. -6 20
  987. -1 -10
  988. 1 10
  989. 3 30
  990. 4 40
  991. 5 50
  992. DROP TABLE t;
  993. # Updating the partition table with a value that crosses the upper limits
  994. # on both the positive and the negative side.
  995. CREATE TABLE t (c1 TINYINT NOT NULL AUTO_INCREMENT, PRIMARY KEY(c1),
  996. c2 INT) ENGINE='InnoDB' PARTITION BY HASH(c1) PARTITIONS 4;
  997. INSERT INTO t(c2) VALUES (10);
  998. INSERT INTO t(c2) VALUES (20);
  999. INSERT INTO t VALUES (126,30);
  1000. INSERT INTO t VALUES (127,40);
  1001. SELECT * FROM t ORDER BY c1 ASC;
  1002. c1 c2
  1003. 1 10
  1004. 2 20
  1005. 126 30
  1006. 127 40
  1007. UPDATE t SET c1 = 130 where c1 = 127;
  1008. Warnings:
  1009. Warning 1264 Out of range value for column 'c1' at row 1
  1010. SELECT * FROM t ORDER BY c1 ASC;
  1011. c1 c2
  1012. 1 10
  1013. 2 20
  1014. 126 30
  1015. 127 40
  1016. UPDATE t SET c1 = -140 where c1 = 126;
  1017. Warnings:
  1018. Warning 1264 Out of range value for column 'c1' at row 1
  1019. SELECT * FROM t ORDER BY c1 ASC;
  1020. c1 c2
  1021. -128 30
  1022. 1 10
  1023. 2 20
  1024. 127 40
  1025. DROP TABLE t;
  1026. ##############################################################################