MapD crashes on simple select query with like


#1

Hello everyone,

I was playing around with MapD CE 4.1.0 and I encountered a weird behaviour.
If you create a table like:

> \d foo
CREATE TABLE foo (
bar TEXT NOT NULL ENCODING DICT(16))

and if you add one row to that:

> insert into foo (bar) values ('mars');

now if you execute simple queries like:

> select * from foo;
bar
mars

> select * from foo where bar = 'mars';
bar
mars

> select * from foo where bar = 'foo2';
No rows returned.

> select * from foo where bar like 'mars';
bar
mars

> select * from foo where bar like 'foo2';
No rows returned.

> select * from foo where bar = 'mars' or bar = 'foo2';
bar
mars

As you can see everything works smoothly but when you launch a query like:

> select * from foo where bar like 'mars' or bar = 'foo2';

the core throws exceptions and the connection it’s broken also no lines are returned:

Thrift: Fri Aug 17 10:00:51 2018 TSocket::write_partial() send() <Host: localhost Port: 9091>Broken pipe
Thrift: Fri Aug 17 10:01:13 2018 TSocket::write_partial() send() <Host: localhost Port: 9091>Broken pipe
Cannot connect to MapD Server.

This is the mapd_server.INFO:

I0817 10:15:21.843036 20200 MapDHandler.cpp:648] sql_execute :yRuPgqINPcQOJCsZ843pTBi1U774C5x6:query_str:select * from foo where bar like 'mars' or bar = 'foo2';
I0817 10:15:21.843441 20200 Calcite.cpp:333] User mapd catalog mapd sql 'select * from foo where bar like 'mars' or bar = 'foo2';'
I0817 10:15:21.863823 20200 Calcite.cpp:346] Time in Thrift 2 (ms), Time in Java Calcite server 18 (ms)
F0817 10:15:21.874444 20200 NativeCodegen.cpp:84] Both operands to a binary operator are not of the same type!
%11 = or i8 %6, i1 %10
I0817 10:15:21.875515 20200 Calcite.cpp:383] Shutting down Calcite server
I0817 10:15:21.880710 20200 Calcite.cpp:392] shut down Calcite
I0817 10:15:21.880869 20200 MapDServer.cpp:108] Interrupt signal (11) received.

Does anyone have any idea about what it’s happening?


#2

Hi,

Thanks for trying out MapD.

You have come across an issue with our NOT NULL processing. The ‘types’ being returned are not being considered the same for the same column and is causing the issues in the analyser.

You will have to drop the NOT NULL for now as a work around. We will be working on a fix in parallel

Work around

create table foo (bar text);
insert into foo values ('mars');

select * from foo where bar like 'mars' or bar = 'foo2';

result is correct

bar
mars

#3

Hi dwayne,

thank you for your reply, I will try it ASAP.
However, since I am curious, can I have some more details about the root cause of the issue?
Is this because, while evaluating the condition, one of the operands returns null and the other returns false?


#4

Hi @francesco.ferretti,

You can find the commit for the fix here. We essentially weren’t treating the return of like on not null text columns correctly.

The fix should be out in 4.2, targeted for the end of next month.

Regards