[MDEV-32555] wrong result with an index and a partially null-rejecting condition Created: 2023-10-23  Updated: 2024-01-11  Resolved: 2023-10-30

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.10, 10.11.5, 11.1.2, 11.3.0
Fix Version/s: 10.10.7, 10.11.6, 11.0.4, 11.1.3, 11.2.2

Type: Bug Priority: Critical
Reporter: Cuchac Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: index, regression-10.10, wrong_result
Environment:

Official docker images


Attachments: File mariadb_index_error.sql    
Issue Links:
Duplicate
is duplicated by MDEV-32090 Index does not handle null-safe equal... Closed

 Description   

Hello,

when I run same query with different indexes (USE INDEX to force another index), I get completely different results. I discovered this issue after upgrade to version 10.11, some queries started to return nonsense. Does work correctly in <10.11.

This fiddle shows the code but does not exhibit the problem (version 10.9 is not affected) - https://dbfiddle.uk/eJwzXdgt both queries returns the same value. But when I run this in 10.11 or 11.1, first query returns all NULLs (invalid result), second query returns valid results.

Queries differ only in index used.

SELECT 
    (
    SELECT
        SUM(ps3.quantity)
    FROM
        products_stores ps3 USE INDEX (products_stores_id_store_id_product_id_variation_uindex)
    WHERE
        ps3.id_product = p.id AND ps3.id_variation <=> ps.id_variation AND ps3.id_store = 1
) AS store3_quantity
FROM
    products_stores ps
LEFT JOIN products p ON
    p.id = ps.id_product;



 Comments   
Comment by Cuchac [ 2023-10-23 ]

Same happens with very latest - 11.3.0 - quay.io/mariadb-foundation/mariadb-devel:verylatest

Comment by Sergei Petrunia [ 2023-10-27 ]

serg, the patch looks good to me.

Please add a comment with a note that

Note that there are no store_key objects for const ref parts.

before this piece of code.

+    while (map & ref->const_ref_part_map)
+      map <<= 1;

Ok to push after that.

Generated at Thu Feb 08 10:32:14 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.