MDEV-24931: Fix Bitmap<64>::is_prefix assertion with >64-column NATURAL JOIN on derived table

[bodyhedia44]

Problem

When a NATURAL JOIN operates on a derived table (or view with derived_merge=off) having more than 64 columns, the server crashes with:
Assertion `prefix_size <= width' failed in Bitmap<64u>::is_prefix

UBSAN also reports: shift exponent 32 is too large for 32-bit type 'int'

Root Cause

generate_derived_keys_for_table() in sql_select.cc creates derived keys with no cap on the number of key parts. When a 65-column table is NATURAL JOINed:

1. Shift overflow: (key_part_map)(1 << parts) — when parts >= 32, this is undefined behavior (shifting a 32-bit 1 by 32+ bits).
2. Bitmap overflow: A derived key with 65 parts is created, but key_map (Bitmap<64>) and key_part_map (uint64) can only track 64 bits.
3. Crash: make_join_statistics() calls eq_part.is_prefix(65) on a Bitmap<64>, hitting the assertion.

How to Reproduce

CREATE DATABASE IF NOT EXISTS test;
USE test;

DROP TABLE IF EXISTS t;

CREATE TABLE t (c1 INT,c2 INT,c3 INT,c4 INT,c5 INT,c6 INT,c7 INT,c8 INT,c9 INT,c10 INT,c11 INT,c12 INT,c13 INT,c14 INT,c15 INT,c16 INT,c17 INT,c18 INT,c19 INT,c20 INT,c21 INT,c22 INT,c23 INT,c24 INT,c25 INT,c26 INT,c27 INT,c28 INT,c29 INT,c30 INT,c31 INT,c32 INT,c33 INT,c34 INT,c35 INT,c36 INT,c37 INT,c38 INT,c39 INT,c40 INT,c41 INT,c42 INT,c43 INT,c44 INT,c45 INT,c46 INT,c47 INT,c48 INT,c49 INT,c50 INT,c51 INT,c52 INT,c53 INT,c54 INT,c55 INT,c56 INT,c57 INT,c58 INT,c59 INT,c60 INT,c61 INT,c62 INT,c63 INT,c64 INT,c65 INT) ENGINE=InnoDB;

SET SESSION optimizer_switch='derived_merge=off';

SELECT * FROM t AS a NATURAL JOIN (SELECT * FROM t) AS b;

DROP TABLE t;

Fix

• Cap derived keys at sizeof(key_part_map) * 8 (64) parts in generate_derived_keys_for_table().
• Excess key parts beyond 64 are excluded (keyuse->key = MAX_KEY).
• Fix the shift to cast before shifting: (key_part_map) 1 << parts instead of (key_part_map)(1 << parts).

Test

Added main.mdev24931 with three cases:

• 65-column derived table via subquery (the crash case).
• 65-column view with derived_merge=off (original bug report).
• 64-column boundary test (should always work).

[gkodinov]

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

[gkodinov]

This should not be sizeof(key_part_map) IMHO. I'd use table->file->max_key_parts() to get the info from the SE.

[gkodinov]

why the extra check here? You are already checking above.

[gkodinov]

Add a comment here mentioning what does setting MAX_KEY to a key really mean.