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

insert into t (select * from t) bogus in multithreaded execution #2883

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

insert into t (select * from t) bogus in multithreaded execution #2883

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

Comments

@monetdb-team
Copy link

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

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).

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.

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:

Partial transplant of changeset [fbe3bda547b2](https://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=fbe3bda547b2)  .
This fixes bug #2883.

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:

Added changelog entries for bug #2882 and bug #2883.

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

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