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
On a multicore system, dataflow can cause that the subject query inserts more into the table than it should.
Using mserver5 --forcemito do:
create table t (i int);
insert into t values (1);
insert into t (select * from t);
insert into t (select * from t);
After these queries there should be 4 elements in t, but I get 6. The reason is that the insertions table is appended to first (assignment to X_44 in trace) before that same table is used to find old inserted values that have to be copied (assignment to X_9 in trace).
Attached file: @2 (application/octet-stream, 2187 bytes)
Description: trace of last insert query
Comment 16227
Date: 2011-09-15 23:39:42 +0200
From: @mlkersten
The cause are the multiple mitosis plans, who each
insert the tuples. All updates should be collected
in a temporary BAT before being inserted into the persistent version.
Could this fix be the cause of orphans on intel Darwin, and complete defunct processes on Solaris? (I just manually killed Python/Mtest, it doesn't seem to reap its childeren correctly)
Date: 2011-09-15 15:45:55 +0200
From: @sjoerdmullender
To: MonetDB5 devs <>
Version: 11.5.1 (Aug2011) [obsolete]
CC: @mlkersten, @yzchang
Blocker for: #2882
Last updated: 2012-11-27 14:44:10 +0100
Comment 16225
Date: 2011-09-15 15:45:55 +0200
From: @sjoerdmullender
Created attachment 73
trace of last insert query
On a multicore system, dataflow can cause that the subject query inserts more into the table than it should.
Using mserver5 --forcemito do:
create table t (i int);
insert into t values (1);
insert into t (select * from t);
insert into t (select * from t);
After these queries there should be 4 elements in t, but I get 6. The reason is that the insertions table is appended to first (assignment to X_44 in trace) before that same table is used to find old inserted values that have to be copied (assignment to X_9 in trace).
Comment 16227
Date: 2011-09-15 23:39:42 +0200
From: @mlkersten
The cause are the multiple mitosis plans, who each
insert the tuples. All updates should be collected
in a temporary BAT before being inserted into the persistent version.
Comment 16228
Date: 2011-09-16 10:13:42 +0200
From: @sjoerdmullender
Changeset 7e2a2426e682 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=7e2a2426e682
Changeset description:
Comment 16286
Date: 2011-09-16 15:48:57 +0200
From: @sjoerdmullender
Changeset c22ffd42d642 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=c22ffd42d642
Changeset description:
Comment 16287
Date: 2011-09-16 15:49:50 +0200
From: @sjoerdmullender
The bug has been fixed. No separate test is needed since the test for bug #2882 covers this issue as well.
Comment 16297
Date: 2011-09-19 15:00:18 +0200
From: @grobian
Could this fix be the cause of orphans on intel Darwin, and complete defunct processes on Solaris? (I just manually killed Python/Mtest, it doesn't seem to reap its childeren correctly)
Comment 16350
Date: 2011-09-30 10:58:44 +0200
From: @grobian
Released in Aug2011-SP1
Comment 18090
Date: 2012-11-27 14:44:10 +0100
From: @yzchang
Covered by the test for bug #2882:
sql/test/BugTracker-2011/Tests/delete-large-table.Bug-2882.sql
The text was updated successfully, but these errors were encountered: