It appears the problem only surfaces in queries with order by 1,2,3,4. The same query with order by 1,2 does not fail.

The query found in working_tpch1_compareLogOnly/view/mts_view.sql

SELECT DISTINCT t2.gid AS lgid,(SELECT t1.name FROM t1, t2 WHERE t1.lid  = t2.lid AND t2.gid = t1.lid and t1.lid =1 ) as clid   FROM t2 order by 1, 2;

also shows this error. Note that it has order by 1,2.

This is caused by an ORDER BY on the returned value of a subquery. Such results don't have oids in the key maps and it gets confused.

mts.1.0200.sql has this query, which is the simplest to exhibit the problem:
select (select a from t3), a from t2 order by 1, 2;

The problem stems from moving order by into our code. Order by, as coded, doesn't see the results of a subquery. In this case, the parser will syntax out (or runtime will error) if the subquery returns more than one value, so ordering on it is redundant. Still, we should support it, as automated query builders may create such things.

A simplified way to reproduce:

CREATE TABLE t2 (a int(11) , b int(11) )engine=columnstore;

CREATE TABLE t3 (a int(11) )engine=columnstore;

insert into t2 values (1,7),(2,7);

insert into t3 values(3);

select (select a from t3), a from t2 order by 1, 2;

An interesting note:

select (select a from t3) c, a from t2 order by c, 2;

will not error. It won't put c in the sort, but it won't error. Since c must be a single value, it doesn't matter that it doesn't get into the sort:

select (select a from t3) c, a from t2 order by c, 2;

+------+------+

| c    | a    |

+------+------+

|    3 |    1 |

|    3 |    2 |

+------+------+

Adding a second value to t3 results in an error which is consistent with InnoDB behavior:

insert into t3 values(4);

select (select a from t3) c, a from t2 order by c, 2;

ERROR 1815 (HY000): Internal error: IDB-3002: Subquery returns more than 1 row.

The problem stems from moving order by into our code. Order by, as coded, doesn't see the results of a subquery. In this case, the parser will syntax out, or runtime will, if the subquery returns more than one row, so ordering on it is redundant. Still, we should support it, as automated query builders may create such things.

A simplified way to reproduce:

CREATE TABLE t2 (a int(11) , b int(11) )engine=columnstore;

CREATE TABLE t3 (a int(11) )engine=columnstore;

insert into t2 values (1,7),(2,7);

insert into t3 values(3);

select (select a from t3), a from t2 order by 1, 2;

An interesting note:

select (select a from t3) c, a from t2 order by c, 2;

will not error. It won't put c in the sort, but it won't error. Since c must be a single value, it doesn't matter that it doesn't get into the sort:

select (select a from t3) c, a from t2 order by c, 2;

+------+------+

| c    | a    |

+------+------+

|    3 |    1 |

|    3 |    2 |

+------+------+

Adding a second value to t3 results in an error:

insert into t3 values(4);

select (select a from t3) c, a from t2 order by c, 2;

ERROR 1815 (HY000): Internal error: IDB-3002: Subquery returns more than 1 row.

Fixed by optimizing out any order by on a scaler subselect. This way, any internal confusion is avoided, and cost of sorting on a single value is saved.

David.Hall Can you reinstate all the relevant regression tests for this fix?

MariaDB [tpch1]> select * from v1 order by 1,2,3,4;
------------------+

------------------+

------------------+

Builds verified: 1.4.5-1 (drone #483), 1.5.4-1 (drone #496)

MariaDB [mytest]> create table t1 (a int, b int) engine=columnstore;
Query OK, 0 rows affected (0.181 sec)

MariaDB [mytest]> insert into t1 values (1,2), (1,3), (2,4), (2,5), (3,10);
Query OK, 5 rows affected (0.775 sec)
Records: 5 Duplicates: 0 Warnings: 0

MariaDB [mytest]> create view v1 (c,d,e,f) as select a,b,
-> (select a+2 from t1 limit 1) e1, (select a from t1 limit 1) f1 from t1;
Query OK, 0 rows affected (0.001 sec)

MariaDB [mytest]> select * from v1 order by 1,2,3,4;
------------------+

------------------+

------------------+
5 rows in set (0.090 sec)