Elena Stepanova added a comment - 2016-01-30 03:19 I'm setting it to critical because the behavior on a release build is really bad. When the same set of queries is executed from a client connection, it hangs. The server remains responsive. You can connect to it, run for example show processlist , but it does not show any activity for the hanging connection, like this (connection 19 is one that is hanging on the query): ariaDB [test]> show processlist; +----+------+-----------------+------+---------+------+-------+------------------+----------+ | Id | User | Host | db | Command | Time | State | Info | Progress | +----+------+-----------------+------+---------+------+-------+------------------+----------+ | 19 | root | localhost:44506 | test | Sleep | 9 | | NULL | 0.000 | | 20 | root | localhost:44507 | test | Query | 0 | init | show processlist | 0.000 | +----+------+-----------------+------+---------+------+-------+------------------+----------+ 2 rows in set (0.00 sec) KILL QUERY does not work: MariaDB [test]> kill query 19; Query OK, 0 rows affected (0.00 sec)   MariaDB [test]> show processlist; +----+------+-----------------+------+---------+------+-------+------------------+----------+ | Id | User | Host | db | Command | Time | State | Info | Progress | +----+------+-----------------+------+---------+------+-------+------------------+----------+ | 19 | root | localhost:44506 | test | Killed | 204 | | NULL | 0.000 | | 21 | root | localhost:44525 | test | Query | 0 | init | show processlist | 0.000 | +----+------+-----------------+------+---------+------+-------+------------------+----------+ 2 rows in set (0.00 sec) Killing the thread works. However, it's nearly impossible for a user to analyze, we will be getting weird complaints about "something hangs", or "something extremely slow", etc. Maybe we already got them, but did not recognize because of the vagueness of the problem. It needs to be fixed asap.

Oleksandr Byelkin added a comment - 2016-01-31 16:13 I checked, it looks like sending OK skipped.

Oleksandr Byelkin added a comment - 2016-02-18 16:16 It is important for reproducing to have materialized IN in the second query: CREATE TABLE t1 (f1 INT); CREATE TABLE t2 (f2 INT); INSERT INTO t1 VALUES (1),(2);   ( SELECT 1 FROM t1 ) UNION ALL ( SELECT 1 FROM t1 WHERE f1 NOT IN ( SELECT f2 FROM t2 ) ) ;   drop table t1,t2;

Oleksandr Byelkin added a comment - 2016-02-18 17:05 The problem is that in the time of execution select_union_direct::send_eof() current SELECT_LEX is not the last select of the union of UNION, we send_eof is not send. JOIN of last select points to the other SELECT_LEX (probably it is the result of materialization)

Oleksandr Byelkin added a comment - 2016-02-18 18:21 revision-id: 1de168b7f354adfb5e2ee07af20b20f7e4ae9075 (mariadb-10.1.11-14-g1de168b) parent(s): 36ca65b73bcd0152680c88e09558bbe1237577ee committer: Oleksandr Byelkin timestamp: 2016-02-18 17:20:48 +0100 message: MDEV-9489 :Assertion `0' failed in Protocol::end_statement() on UNION ALL Restoring currect_select fixed.

Oleksandr Byelkin added a comment - 2016-02-18 18:46 The bug is present in 5.5/10.0 but test suite is not repetable

Sergei Petrunia added a comment - 2016-02-19 13:10 Ok to push.