[MCOL-4278] Select count(*) may leave table in a bad state Created: 2020-08-26  Updated: 2020-10-05  Resolved: 2020-09-25

Status: Closed
Project: MariaDB ColumnStore
Component/s: MDB Plugin
Affects Version/s: 1.4, 1.5.3
Fix Version/s: 5.4.1

Type: Bug Priority: Blocker
Reporter: David Hall (Inactive) Assignee: Daniel Lee (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MCOL-4324 Query might return unexpected values ... Open
relates to MCOL-4026 Regression in working_tpch1_compareLo... Closed

 Description   

If @@sql_select_limit is set, followed by a select count, then the following queries may report wrong results. count(<colname>) has the same behavior.

This behavior is intermittent, meaning it may or may not happen on any given attempt.

2147483647 is max int32_t.

MariaDB [tpch1]> set @@sql_select_limit=4;
Query OK, 0 rows affected (0.001 sec)
 
MariaDB [tpch1]> create table if not exists bug5054(id int)engine=columnstore; 
Query OK, 0 rows affected (0.519 sec)
 
MariaDB [tpch1]> insert into bug5054 values (1),(2),(3),(4),(5),(6),(7),(8); 
Query OK, 8 rows affected (0.591 sec)
Records: 8  Duplicates: 0  Warnings: 0
 
MariaDB [tpch1]> select * from bug5054; 
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
+------+
4 rows in set (0.112 sec)  // Only 4 are shown because of sql_select_limit
 
MariaDB [tpch1]> select count(*) from bug5054; 
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (2.384 sec)
 
MariaDB [tpch1]> select * from bug5054 limit 10; 
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
|    5 |
|    6 |
|    7 |
|    8 |
+------+
8 rows in set (1.774 sec)  // Didn't break this time
 
MariaDB [tpch1]> select count(*) from bug5054; 
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (1.877 sec)
 
MariaDB [tpch1]> select * from bug5054 limit 10; 
+------------+
| id         |
+------------+
| 2147483647 |
| 2147483647 |
| 2147483647 |
| 2147483647 |
| 2147483647 |
| 2147483647 |
| 2147483647 |
| 2147483647 |
+------------+
8 rows in set (2.808 sec)

########################################
At this point, in another console:

systemctl stop mariadb
systemctl start mariadb

Do not restart mariadb-columnstore.
Restarting the mysqld process clears up the problem with the table.

MariaDB [tpch1]> select * from bug5054 limit 10; 
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    3
Current database: tpch1
 
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
|    5 |
|    6 |
|    7 |
|    8 |
+------+
8 rows in set (0.233 sec)



 Comments   
Comment by Roman [ 2020-09-02 ]

I haven't seen this issue in U18. I'll check centos.

Comment by Daniel Lee (Inactive) [ 2020-09-22 ]

Build tested: 1.5.4-1 ( Drone #689)

Reproduced the issue at first attempt. My environment is a Vagrant virtual machine.

Comment by Roman [ 2020-09-24 ]

The issue had been caused by the code in rnd_end() in the plugin. The code quits early when sql_select_limit is set so that smart pointer to cpsm_tplsch_t hangs in the air and is used for the next query. cpsm_tplsch_t contains Column types so that forces fetchNextRow to use an incorrect accessor retrieving the column value, e.g. getUintvalue<8>() for an INT column.
I believe we'll see more issues of this kind b/c the code doesn't clean up cpsm_tplsch_t smart pointer processing query kill requests but I'll open another issue to track this down.

Comment by Roman [ 2020-09-24 ]

Plz review.

Comment by Daniel Lee (Inactive) [ 2020-09-25 ]

Build verified: 5.4.1 (Drone #759)

Generated at Thu Feb 08 02:49:09 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.