mariadb

Tree: 9ecdd588c5

Author	SHA1	Message	Date
Mattias Jonsson	25596746db	Bug#50392: insert_id is not reset for partitioned tables auto_increment on duplicate entry The bug was that when INSERT_ID was used and the storage engine was told to release any reserved but not used auto_increment values, it set the highest auto_increment value to INSERT_ID. The fix was to check if the auto_increment value was forced by user (INSERT_ID) or by slave-thread, i.e. not auto- generated. So that it is only allowed to release generated values.	16 years ago
Mattias Jonsson	abd09620db	Bug#14326: No formatting of partitioning clause in SHOW CREATE TABLE output The partitioning clause is only a very long single line, which is very hard to interpret for a human. This patch breaks the partitioning syntax into one line for the partitioning type, and one line per partition/subpartition.	17 years ago
Mattias Jonsson	5e353415f8	Bug#40176: update as first partitioning statement breaks auto increment The auto_increment value was not initialized if the first statement after opening a table was an 'UPDATE'. solution was to check initialize if it was not, before trying to increase it in update.	17 years ago
Mattias Jonsson	5b164964e2	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

5 Commits (9ecdd588c54c4496cb9f5b566176aa3be2c6c6dc)