Index on DOUBLE Column Causes Wrong Results with semijoin=off IN Subquery

1. Minimal reproduce step

DROP DATABASE IF EXISTS b; CREATE DATABASE b; USE b;
CREATE TABLE t0 (c1 DOUBLE) ENGINE=InnoDB;
INSERT INTO t0 VALUES (1.7976931348623157E308);
INSERT INTO t0 VALUES (0),(1860218557),(1926237111),(0.21213754627564751),(1625945190),
(0.9110275762374198),(2045499401),(0.7912975663167398),(99584196),(0.07404853020410118),
(432694662),(0.4350032920718634);
CREATE TABLE idx_t0 (c5 VARCHAR(255)) ENGINE=InnoDB;
INSERT INTO idx_t0 VALUES ('1e500'),('0'),('1860218557'),('1926237111'),('0.21213754627564751'),('x');
CREATE INDEX t0_c1 ON t0 (c1);
CREATE INDEX idx_t0_c5 ON idx_t0 (c5);
ANALYZE TABLE t0, idx_t0;

-- [CORRECT] semijoin=ON (default)
SELECT '[CORRECT] semijoin=ON' AS plan, COUNT(*) FROM t0 WHERE c1 IN (SELECT c5 FROM idx_t0);

-- [BUG] semijoin=OFF
SET SESSION optimizer_switch = 'semijoin=off';
SELECT '[BUG]    semijoin=OFF' AS plan, COUNT(*) FROM t0 WHERE c1 IN (SELECT c5 FROM idx_t0);
SET SESSION optimizer_switch = 'default';

2. What did you expect to see?

Both queries should return the same count (4):

plan                    COUNT(*)
[CORRECT] semijoin=ON   4
[BUG]    semijoin=OFF   4

3. What did you see instead

semijoin=OFF returns one extra row (5 vs 4):

plan                    COUNT(*)
[CORRECT] semijoin=ON   4
[BUG]    semijoin=OFF   5

The extra row: t0.c1 = 1.7976931348623157E308 (Double.MAX_VALUE). The idx_t0 value '1e500' (which casts to DOUBLE Infinity) matches Double.MAX_VALUE only when semijoin=OFF. With semijoin=ON, Infinity != Double.MAX_VALUE (correct behavior).

Trigger condition: An index on t0(c1) must exist. Without it, both plans return the same result.

4. What is your PolarDB-X version?

VERSION(): 5.6.29-PXC-5.4.19-20250825

Docker image: polardbx/polardb-x:v2.4.2_5.4.19

Start by running the supplied SQL reproducer on PolarDB-X and compare semijoin=ON with semijoin=OFF, both with and without the t0(c1) index. Trace the semijoin-off indexed IN-subquery path and its DOUBLE conversion behavior. Done means both plans return a count of 4, including the Double.MAX_VALUE case, with coverage for the trigger conditions.