[MDEV-22861] INSERT with subquery on I_S.PROCESSLIST fails when EXAMINED_ROWS value range is exceeded Created: 2020-06-10  Updated: 2023-04-27

Status: Stalled
Project: MariaDB Server
Component/s: Data Manipulation - Insert, Information Schema
Affects Version/s: 10.3.22, 10.2.32, 10.4.13, 10.5.3
Fix Version/s: 10.4, 10.5

Type: Bug Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Oleksandr Byelkin
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-22860 Change EXAMINED_ROWS in I_S.PROCESSLI... Closed

 Description   

When using the INFORMATION_SCHEMA.PROCESSLIST table in a subquery in an INSERT or UPDATE statement the statement will fail with:

ERROR 1264 (22003): Out of range value for column 'EXAMINED_ROWS' at row 1

if there's a running query in another session that exceeds the EXAMINED_ROWS value range (see also MDEV-22860) and sql_mode=STRICT_TRANS_TABLE is set, otherwise it will just cause a warning.

Just querying the PROCESSLIST table works fine, e.g.:

> select * from processlist where examined_rows > 0\G
*************************** 1. row ***************************
             ID: 12
           USER: root
           HOST: localhost
             DB: test
        COMMAND: Query
           TIME: 265
          STATE: Updating
           INFO: update t2 set id=1 where id=23
        TIME_MS: 265257.998
          STAGE: 0
      MAX_STAGE: 0
       PROGRESS: 0.000
    MEMORY_USED: 77944
MAX_MEMORY_USED: 2211464
  EXAMINED_ROWS: 2147483647
       QUERY_ID: 120
    INFO_BINARY: update t2 set id=1 where id=23
            TID: 5414
1 row in set (0.002 sec)

Note that EXAMINED_ROWS is already at the max. value of 2147483647 here.

This query does not even return a truncation warning, even with

sql_mode=STRICT_TRANS_TABLE,STRICT_ALL_TABLES

is in effect.

Using the PROCESSLIST table in a subquery in an outer SELECT also doesnt't cause any troubles at all, no errors no warnigs. Note that this query does not even use the EXAMINED_ROWS column, and due to the WHERE condition only the row for the current session is selected anyway, not the one of the other session exceeding the row column:

SELECT (SELECT HOST FROM information_schema.processlist WHERE ID=CONNECTION_ID()) as foo;

But when using this in an INSERT, it fails:

> INSERT INTO test.t3 (machine_name) values ( (SELECT HOST FROM information_schema.processlist WHERE ID=CONNECTION_ID()));
ERROR 1264 (22003): Out of range value for column 'EXAMINED_ROWS' at row 1
 
> INSERT INTO test.t3 SET machine_name = ( (SELECT HOST FROM information_schema.processlist WHERE ID=CONNECTION_ID()));
ERROR 1264 (22003): Out of range value for column 'EXAMINED_ROWS' at row 1

Direct INSERT...SELECT works, but when adding a subquery it fails again:

> INSERT INTO test.t3 SELECT HOST FROM information_schema.processlist WHERE ID=CONNECTION_ID();
Query OK, 1 row affected (0.007 sec)
Records: 1  Duplicates: 0  Warnings: 0
 
> INSERT INTO test.t3 SELECT (SELECT HOST FROM information_schema.processlist WHERE ID=CONNECTION_ID()) as foo;
ERROR 1264 (22003): Out of range value for column 'EXAMINED_ROWS' at row 1

Changing EXAMINED_ROWS from INT to BIGINT UNSIGNED will probably fix this without any additional code changes, as a DML query having to scan more than 2^64 is far less likely (nobody is probably going to wait for that to complete anyway?), but this should probably still be fixed anyway as there may by other situations where values exceed the I_S column types used for them ...



 Comments   
Comment by Hartmut Holzgraefe [ 2020-06-10 ]

How to reproduce:

  • create a table with much more than two billion rows
  • create a 2nd table (test.t3 in the example queries above) with just one column "machine_name varchar(100))"
  • do an UPDATE on that table that requires a full table scan
  • wait until I_S.PROCESSLIST.EXAMINED_ROWS reaches 2147483647
  • try the queries listed above in initial description
Generated at Thu Feb 08 09:18:02 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.