MDEV-40995 Fix AUTO_INCREMENT race condition in partitioned tables

[greypilgrim-083]

Fixes https://jira.mariadb.org/browse/MDEV-40995

The Problem:
When a multi-row insert (or INSERT ... SELECT) fails on the first row of a newly fetched auto-increment block, restore_auto_increment rolls the ID pointer backward into an older block. During cleanup, ha_partition::release_auto_increment blindly trusted this pointer because it only checked the .maximum() boundary. This allowed the global counter to be forcefully lowered into already-used territory, resulting in ER_DUP_ENTRY PRIMARY key collisions under concurrent load.

The Fix:
Added a .minimum() boundary check (next_insert_id >= auto_inc_interval_for_cur_row.minimum()) inside ha_partition::release_auto_increment. This ensures the global counter is never rolled back below the starting ID of the currently reserved block.

Testing Note:
A regression .test file is not included because this is a strict multi-threaded race condition. Reliably interleaving the auto-increment block fetches across multiple connections to force the collision would require injecting explicit DEBUG_SYNC points into the C++ source. The fix has been thoroughly validated locally using the reporter's 02_run.sh concurrent stress test.

Please let me know if you would like me to wire up the DEBUG_SYNC sync points and write the MTR test for this, or if the C++ fix is sufficient as-is!

for more detailed analysis of problem please check my comment under https://jira.mariadb.org/browse/MDEV-40995

[CLAassistant]

All committers have signed the CLA.

[greypilgrim-083]

I took a look at the recent CI failures and they appear to be unrelated flaky tests. The specific tests that failed are:

main.start_slave_until (replication parser test)
perfschema.bad_option (server startup option parser test)
binlog_encryption.encrypted_master (encrypted binlog test)
Since my patch strictly modifies auto-increment boundary logic for partitioned tables (ha_partition.cc), it doesn't interact with replication parsing or server startup options. These look like intermittent timing/load issues on the CI runners.

Could a maintainer please re-trigger the failed Buildbot jobs for me when they have a chance?

Thanks!

[gkodinov]

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

Please rebase your fix to 10.11: every bug should be fixed in the lowest affected version.
Also, please make sure there is a commit comment and it is compliant with the contribution guidelines.

[greypilgrim-083]

@gkodinov I changed the base branch to 10.11 and added commit message according to contribution guidelines of mariadb

[gkodinov]

LGTM.

One suggestion: since this is only reproducible by a probability multi-threaded run, please consider working on a regression test using the dbug tools (DBUG_SYNC/DBUG_EXECUTE_IF etc).

Please also stand by 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

[greypilgrim-083]

@gkodinov @holyfoot can you review the changes?

[gkodinov]

Still LGTM. Thanks for working out a test case! Please stand by for the final review.

[greypilgrim-083]

.

[gkodinov]

Still looking good to me. Please be patient about the final review. These are usually done by the senior developers and usually do take a little bit more time as these people have quite a lot on their hands.

[holyfoot]

The bugfix looks good.
The test requires some work though. The present one just doesn't work as the CREATE TABLE there fails (UNIQUE is not in the partition key).
Also it has to be placed inside already existing suite/parts directory.

[greypilgrim-083]

@gkodinov @holyfoot i updated the unit test and verified it on my system. can you review it?

[gkodinov]

LGTM. Thanks. FYI: no need to re-request my review every time you change something that the final reviewer asks for.