MDEV-40874 Wrong UPDATE change count for NULL fields on Aria

[FarihaIS]

Description

UPDATE ... SET col=DEFAULT on a row that is already NULL changes nothing but Aria counted it as Changed: 1 while InnoDB said Changed: 0.

compare_record()'s fast path memcmps the whole record, including the data bytes of NULL fields, which are undefined. A leftover value there made the row look changed. Skip the fast path when the table has nullable fields, and skip NULL fields in the per-field compare.

Add a test to main.default.

Release Notes

N/A

How can this PR be tested?

Execute the main suite in mysql-test-run.

This commit adds a test in the default test of the main suite (main.default).

Before the fix

Running main.default (with the added test) fails as below:

main.default                             [ fail ]
        Test ended at 2026-08-27 17:59:20

CURRENT_TEST: main.default
--- /quick-rebuilds/mariadb-server/mysql-test/main/default.result 2026-08-27 17:56:26.034947027 +0000
+++ /quick-rebuilds/mariadb-server/mysql-test/main/default.reject 2026-08-27 17:59:20.650054696 +0000
@@ -3511,8 +3511,8 @@
 insert into t1 values (null);
 affected rows: 1
 update t1 set c=default;
-affected rows: 0
-info: Rows matched: 1  Changed: 0  Warnings: 0
+affected rows: 1
+info: Rows matched: 1  Changed: 1  Warnings: 0
 # A real change is still detected
 update t1 set c=1.5;
 affected rows: 1

Result content mismatch

After the fix

Running main.default (with the added test) succeeds:

main.default                             [ pass ]    711

Basing the PR against the correct MariaDB version

• This is a bug fix, and the PR is based against the earliest maintained branch on which the bug can be reproduced: 10.11.

Copyright

All new code of the whole pull request, including one or several files that are either new files or modified ones, are contributed under the BSD-new license. I am contributing on behalf of my employer Amazon Web Services, Inc.

[Copilot]

Pull request overview

Fixes Aria reporting an incorrect “Changed” row count for UPDATE ... SET col=DEFAULT when the column is already NULL, by preventing comparisons against undefined data bytes for NULL fields and adding a regression test to ensure Aria and InnoDB behave consistently.

Changes:

• Disable whole-record fast-path comparison when the table has any nullable fields (avoids memcmp on undefined NULL payload bytes).
• Skip per-field binary comparisons for fields that are NULL (after confirming NULL-bits match), preventing false “row changed” detection.
• Add/record a regression test in main.default covering both InnoDB and Aria behavior for DEFAULT on NULL.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
sql/table.cc	Prevents enabling whole-record comparison when nullable fields exist, avoiding undefined-byte comparisons.
sql/sql_update.cc	Updates compare_record() to skip comparing value bytes for NULL fields while still detecting real changes.
mysql-test/main/default.test	Adds a regression test that reproduces and validates the affected-row/Changed count behavior across engines.
mysql-test/main/default.result	Captures the expected output for the new regression test.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[gkodinov]

Thank you for your contribution! This is a preliminary review.

I wonder if the whole thing is needed for innodb (or any other storage engine).
Or if you are fixing it at the right layer.
If not setting the row part for a NULL column is just an Aria thing why should the other storage engines need to suffer from not choosing the memcmp() route?

Maybe instead you could make Aria do that too?

Anyway, something to consider, while waiting for the final review.

[gkodinov]

FYI: According to our development cycle we work on bugs In the following periods 15 Mar-30 Apr, 15 Jun-30 Jul, 15 Sep-30 Oct and 15 Dec-31 Jan. So, please, expect to get a review somewhere between these two dates and the goal is to have your PR merged before the second date