Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Database crashes after generate_series query #6196

Closed
monetdb-team opened this issue Nov 30, 2020 · 0 comments
Closed

Database crashes after generate_series query #6196

monetdb-team opened this issue Nov 30, 2020 · 0 comments

Comments

@monetdb-team
Copy link

@monetdb-team monetdb-team commented Nov 30, 2020

Date: 2017-01-27 13:59:53 +0100
From: @rkoopmanschap
To: SQL devs <>
Version: 11.23.13 (Jun2016-SP2)
CC: @kutsurak, @mlkersten, @njnes

Last updated: 2017-03-03 10:24:41 +0100

Comment 24929

Date: 2017-01-27 13:59:53 +0100
From: @rkoopmanschap

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
Build Identifier:

The command below crashes MonetDB. The function returns a table and so this is not the correct way to call it. However, it would be better if it did not cause a crash and instead returned an error.

Reproducible: Always

Steps to Reproduce:

Give the following command in mclient:
SELECT generate_series(1,4);

Actual Results:

Database crashes

Expected Results:

An error message

Comment 24930

Date: 2017-01-27 22:34:43 +0100
From: @mlkersten

The generator function is called in the FROM clause.
select * from generate_series(1,4);

However, this short cut makes sense as well
sql>explain select generate_series(1,4);
+-------------------------------------------------------------------------------------------------+
| mal |
+=================================================================================================+
| function user.s6_1():void; |
| X_3:void := querylog.define("explain select generate_series(1,4);", "default_pipe", 8:int); |
| X_9:bat[:bte] := generator.series(1:bte, 4:bte); |
| sql.resultSet(".L2", "L2", "tinyint", 8:int, 0:int, 7:int, X_9); |
| end user.s6_1;

However, now a crash occurs in mvc_scalar_value_wrap which assumes a scalar and not a BAT. The MAL signature allows for any type.

Comment 24931

Date: 2017-01-27 22:46:41 +0100
From: @sjoerdmullender

Also see bug #3609 which was basically the same problem, except with the three argument version of generate_series. The difference is that the two argument version goes through rel_binop and the three argument version through rel_nop. The latter was fixed, the former wasn't.

Comment 24932

Date: 2017-01-27 22:51:20 +0100
From: @kutsurak

The problem is related to binary operators returning tables. Specifically

sql>SELECT 1 + 3;
+------+
| L2 |
+======+
| 4 |
+------+
1 tuple (0.693ms)

works correctly. On the other hand:

sql>SELECT generate_series(1, 4, 2);
SELECT: no such operator 'generate_series'

Furthermore:

sql>CREATE FUNCTION ser(i integer, j integer) RETURNS TABLE(foo integer) LANGUAGE PYTHON {
more>result = dict()
more>result['foo'] = list(range(i, j))
more>return result
more>};
operation successful (8.281ms)
sql>select ser(1, 4);

server crashes

I think that the correct behavior is the parse error as in the three argument case (maybe with a more informative error message).

Comment 24935

Date: 2017-02-01 13:41:34 +0100
From: MonetDB Mercurial Repository <>

Changeset 4ecdec1a1ebf made by Niels Nes niels@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=4ecdec1a1ebf

Changeset description:

fixed bug #6196. Make sure we correctly check the cardinality of table functions.

Comment 24936

Date: 2017-02-01 13:46:09 +0100
From: @njnes

solved by properly checking when table functions are allowed

Comment 25124

Date: 2017-03-03 10:24:41 +0100
From: @sjoerdmullender

Dec2016-SP2 has been released, incorporating the fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant