You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15
Build Identifier:
If I stop a long running INSERT INTO query with sys.stop, or sys.pause and then sys.stop, the query is eventually stopped, but subsequent queries on this table returns "BATproject: does not match always". Don't know if sys.stop is the only culprit, or sys.pause as well.
This problem is a bit nasty, because simple queries such as "select count(*) from t" and "select * from t limit 1" work correctly. You only notice the problem, if you actually touch more/all data of the table, e.g. with "select * from t where id = NNN".
Reproducible: Always
Steps to Reproduce:
In mclient 1: create a dummy test table "t" in an empty database:
create table t as select * from _tables;
insert into t select * from t;
Repeat the INSERT INTO query until its exec. time is long enough
In another mclient connection, execute
select * from sys.queue;
to find the qtag of the INSERT query
4. Execute
call sys.stop();
5. In mclient 1, execute:
select * from t where id = 2001;
then you'll get the error:
client1:!ERROR: BATproject: does not match always
client1:!ERROR:MALException:algebra.projection:GDK reported error: BATproject: does not match always
GDK reported error: BATproject: does not match always
The first werid thing is that the interrupted query did not produce any kind of error message. I would expect it to fail with an error saying that the query was brutally stopped.
Also, since I was running the server under gdb with some breakpoints that would trigger on any kind of error, I saw that no error was generated in the long running query by the call to sys.stop. This may very well be the problem: no error means no error handling.
Adding tests is difficult, but I tested it by hand and stopping an INSERT INTO query no longer break my table. Also tested on stopping an UPDATE query.
The text was updated successfully, but these errors were encountered:
Date: 2019-07-12 21:20:33 +0200
From: @yzchang
To: GDK devs <>
Version: 11.33.3 (Apr2019)
CC: @yzchang
Last updated: 2019-09-02 16:05:27 +0200
Comment 27134
Date: 2019-07-12 21:20:33 +0200
From: @yzchang
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15
Build Identifier:
If I stop a long running INSERT INTO query with sys.stop, or sys.pause and then sys.stop, the query is eventually stopped, but subsequent queries on this table returns "BATproject: does not match always". Don't know if sys.stop is the only culprit, or sys.pause as well.
This problem is a bit nasty, because simple queries such as "select count(*) from t" and "select * from t limit 1" work correctly. You only notice the problem, if you actually touch more/all data of the table, e.g. with "select * from t where id = NNN".
Reproducible: Always
Steps to Reproduce:
create table t as select * from _tables;
insert into t select * from t;
select * from sys.queue;
to find the qtag of the INSERT query
4. Execute
call sys.stop();
5. In mclient 1, execute:
select * from t where id = 2001;
then you'll get the error:
client1:!ERROR: BATproject: does not match always
client1:!ERROR:MALException:algebra.projection:GDK reported error: BATproject: does not match always
GDK reported error: BATproject: does not match always
Comment 27135
Date: 2019-07-13 10:07:52 +0200
From: @sjoerdmullender
I was able to reproduce this.
The first werid thing is that the interrupted query did not produce any kind of error message. I would expect it to fail with an error saying that the query was brutally stopped.
Also, since I was running the server under gdb with some breakpoints that would trigger on any kind of error, I saw that no error was generated in the long running query by the call to sys.stop. This may very well be the problem: no error means no error handling.
Comment 27136
Date: 2019-07-13 10:33:57 +0200
From: MonetDB Mercurial Repository <>
Changeset 1d6e8def4946 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see https//devmonetdborg/hg/MonetDB?cmd=changeset;node=1d6e8def4946
Changeset description:
Comment 27140
Date: 2019-07-15 17:21:59 +0200
From: @yzchang
Adding tests is difficult, but I tested it by hand and stopping an INSERT INTO query no longer break my table. Also tested on stopping an UPDATE query.
The text was updated successfully, but these errors were encountered: