Re: af51be1106b: MDEV-32837 long unique does not work like unique key when using replace
Hi, Alexander, Generally, ok to push. One request for a change and one question below: On Jan 23, Alexander Barkov wrote:
revision-id: af51be1106b (mariadb-10.5.23-57-gaf51be1106b) parent(s): c9902a20b3a author: Alexander Barkov committer: Alexander Barkov timestamp: 2024-01-17 15:51:54 +0400 message:
MDEV-32837 long unique does not work like unique key when using replace
write_record() when performing REPLACE has an optimization: - if the unique violation happened in the last unique key, then do UPDATE - otherwise, do DELETE+INSERT
This patch skips this optimization in case if a non-versioned table has hash unique (i.e. UNIQUE..USING HASH) constraints.
Rationale:
hash unique constraints are checked before regular unique indexes, so even if a hash unique is the last unique constraint in the table->key_info[] array - it guarantees nothing - there still can be regular (non-hash) contraints that violate as well. So just go the non-optmized path with DELETE followed by INSERT on the next loop iteration.
Don't forget to update the commit comment to match the final fix.
diff --git a/mysql-test/main/long_unique_bugs_no_protocol.test b/mysql-test/main/long_unique_bugs_no_protocol.test new file mode 100644 index 00000000000..a6f1f8e57e8 --- /dev/null +++ b/mysql-test/main/long_unique_bugs_no_protocol.test @@ -0,0 +1,61 @@ +--source include/no_protocol.inc
why no protocol? Regards, Sergei Chief Architect, MariaDB Server and security@mariadb.org
Hello Sergei, On 1/24/24 00:17, Sergei Golubchik wrote:
Hi, Alexander,
Generally, ok to push.
One request for a change and one question below:
On Jan 23, Alexander Barkov wrote:
revision-id: af51be1106b (mariadb-10.5.23-57-gaf51be1106b) parent(s): c9902a20b3a author: Alexander Barkov committer: Alexander Barkov timestamp: 2024-01-17 15:51:54 +0400 message:
MDEV-32837 long unique does not work like unique key when using replace
write_record() when performing REPLACE has an optimization: - if the unique violation happened in the last unique key, then do UPDATE - otherwise, do DELETE+INSERT
This patch skips this optimization in case if a non-versioned table has hash unique (i.e. UNIQUE..USING HASH) constraints.
Rationale:
hash unique constraints are checked before regular unique indexes, so even if a hash unique is the last unique constraint in the table->key_info[] array - it guarantees nothing - there still can be regular (non-hash) contraints that violate as well. So just go the non-optmized path with DELETE followed by INSERT on the next loop iteration.
Don't forget to update the commit comment to match the final fix.
Thanks. Updated.
diff --git a/mysql-test/main/long_unique_bugs_no_protocol.test b/mysql-test/main/long_unique_bugs_no_protocol.test new file mode 100644 index 00000000000..a6f1f8e57e8 --- /dev/null +++ b/mysql-test/main/long_unique_bugs_no_protocol.test @@ -0,0 +1,61 @@ +--source include/no_protocol.inc
why no protocol?
With --sp-protocol it produces a different output for Handler commands in the SHOW STATUS output.
Regards, Sergei Chief Architect, MariaDB Server and security@mariadb.org
participants (2)
-
Alexander Barkov
-
Sergei Golubchik