MDEV-39440: replay context throwed a warning for a query after altering an index

[bsrikanth-mariadb]

The problem is that handler->multi_range_read_info_const() call in check_quick_select() returned rows equal to HA_POS_ERROR, both during context capture and replay. However, we never stored the ranges info into the context when rows=HA_POS_ERROR. However, during replay, we try to infuse stats for the given range, and since no match was found in the context, we produced a warning.

Solution is to store range_info for all the ranges even when they get HA_POS_ERROR number of rows.

[gemini-code-assist]

Code Review

This pull request adds a regression test for MDEV-39440 and modifies sql/opt_range.cc to move the optimizer context recording logic. A review comment correctly identifies that this change could lead to the use of uninitialized max_index_blocks and max_row_blocks variables when the row count is invalid, suggesting they be initialized to zero to prevent recording garbage data.

[gemini-code-assist]

The range->max_index_blocks and range->max_row_blocks fields are only assigned values when rows != HA_POS_ERROR (lines 12557-12561 in the original code). Since the recording logic has been moved outside of this conditional block (lines 12591-12597), these fields will contain uninitialized values when rows == HA_POS_ERROR, which are then passed to rec->record_multi_range_read_info_const. These should be initialized to a safe default value (e.g., 0) to avoid recording garbage data and potential undefined behavior.

  TABLE::OPT_RANGE *range= param->table->opt_range + keynr;
  range->max_index_blocks= range->max_row_blocks= 0;