MDEV-40762 Wrong MAX() result with GROUP BY when loose index scan uses DESC key part

[DerZc]

GROUP BY with MAX() can return the wrong extremum when loose index scan considers indexes with different key-part ordering. A later candidate index can corrupt the metadata retained for the selected plan.

Bug report: https://jira.mariadb.org/browse/MDEV-40762

Root cause

Index enumeration writes the current MIN/MAX argument key part directly into the variable that describes the best plan. If another index is inspected but not selected, the chosen index and its argument-key metadata can come from different candidates.

Changes

• Track the MIN/MAX argument key part in a variable local to each candidate index.
• Use that candidate-local pointer for gap, infix, and predicate checks.
• Copy the pointer into the selected plan only when that candidate becomes the best index.

Regression coverage

The regression creates ascending and descending indexes over the grouping and aggregate columns, then checks that MAX(v) for values 1, 2, and 3 returns 3. It explicitly uses InnoDB.

• mysql-test/main/group_min_max_index_order.result
• mysql-test/main/group_min_max_index_order.test

Validation

On 12.3 at 881b64e8add374802e1871814dd0a3a673a9b3e6:

• The server build passed.
• main.group_min_max_index_order failed on the unchanged target branch and passed with this fix.
• Existing MTR tests passed: main.func_group, main.group_by, main.select.
• MTR reported no test-state cleanup failures.
• The full regression suite was not run.

[CLAassistant]

All committers have signed the CLA.