Strange concurrency issue
Dear MonetDB Team, We're starting to exercise our MonetDB installation more heavily now and I've run into a strange issue where I get an occasional "COMMIT: failed" message. It seems that the conditions required to produce this are: - Concurrently inserting into two different tables - At the same time, issuing a SELECT COUNT(*) against either of those tables I've logged a bug with more detailed information, including a Java test case: http://bugs.monetdb.org/show_bug.cgi?id=3210 I'm only just starting my investigation, but I suspect that COUNT(*) may be the culprit, since other selects like SELECT * don't seem to have this problem. Does this ring any bells? Are there any special optimizations for COUNT(*) that bypass the underlying BAT and/or have side effects on some shared table somewhere that could be causing a concurrency violation? Thanks, -- Percy Wegmann +1 512 637 8500 ext 148 _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
Hi Percy, we had a similar problem with prepared statements in the past and since I saw in your bug report that the problem occurs when you are using prepared statements, then it might be related to yours. The problem was that we were creating a prepared statement, then doing an update on the database schema, and then executing the prepared statement. The second step (the update of the database schema) drops any identifiers created for keeping references to prepared statements. The answer of Fabian to this may be found at http://mail.monetdb.org/pipermail/users-list/2012-February/005417.html. Hope that helps, Babis On Tue, Dec 18, 2012 at 12:59 AM, Percy Wegmann <percy@clicksecurity.com> wrote:
Dear MonetDB Team,
We're starting to exercise our MonetDB installation more heavily now and I've run into a strange issue where I get an occasional "COMMIT: failed" message.
It seems that the conditions required to produce this are:
- Concurrently inserting into two different tables - At the same time, issuing a SELECT COUNT(*) against either of those tables
I've logged a bug with more detailed information, including a Java test case:
http://bugs.monetdb.org/show_bug.cgi?id=3210
I'm only just starting my investigation, but I suspect that COUNT(*) may be the culprit, since other selects like SELECT * don't seem to have this problem.
Does this ring any bells? Are there any special optimizations for COUNT(*) that bypass the underlying BAT and/or have side effects on some shared table somewhere that could be causing a concurrency violation?
Thanks,
--
Percy Wegmann +1 512 637 8500 ext 148
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
Hi Babis, Thanks for that link! Unfortunately, I think I'm seeing a different problem, since I'm not actually doing any DDL. I found that the SQL state I'm getting is 2D000, which seems to correspond to an error in calling mvc_commit(). Time to debug! Thank You, Percy On Tue, Dec 18, 2012 at 3:48 AM, Charalampos Nikolaou <charnik@di.uoa.gr>wrote:
Hi Percy,
we had a similar problem with prepared statements in the past and since I saw in your bug report that the problem occurs when you are using prepared statements, then it might be related to yours. The problem was that we were creating a prepared statement, then doing an update on the database schema, and then executing the prepared statement. The second step (the update of the database schema) drops any identifiers created for keeping references to prepared statements.
The answer of Fabian to this may be found at http://mail.monetdb.org/pipermail/users-list/2012-February/005417.html.
Hope that helps, Babis
Dear MonetDB Team,
We're starting to exercise our MonetDB installation more heavily now and I've run into a strange issue where I get an occasional "COMMIT: failed" message.
It seems that the conditions required to produce this are:
- Concurrently inserting into two different tables - At the same time, issuing a SELECT COUNT(*) against either of those
On Tue, Dec 18, 2012 at 12:59 AM, Percy Wegmann <percy@clicksecurity.com> wrote: tables
I've logged a bug with more detailed information, including a Java test case:
http://bugs.monetdb.org/show_bug.cgi?id=3210
I'm only just starting my investigation, but I suspect that COUNT(*) may
the culprit, since other selects like SELECT * don't seem to have this problem.
Does this ring any bells? Are there any special optimizations for COUNT(*) that bypass the underlying BAT and/or have side effects on some shared
be table
somewhere that could be causing a concurrency violation?
Thanks,
--
Percy Wegmann +1 512 637 8500 ext 148
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
-- Percy Wegmann +1 512 637 8500 ext 148 _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
Okay, I've traced this to the bind_col function in bat_storage.c. It turns out that this happens with any SELECT, I was probably just more likely to see it on a SELECT COUNT because that accessed more rows. bind_col calls bind_ucol which will update the rtime of the column if there is a transaction in progress and the access level is RD_UPD. I added some debug logging and found that: - Running a SELECT COUNT(*) causes bind_col to be called for the first column in the table - SELECT * causes bind_col to be called for all columns in the table - In both cases, update_col is called multiple times for each column, at least one of which is called with access = RD_UPD This raises the following questions: 1. What about doing a select causes bind_col to be called with access = RD_UPD (I'm debugging to find this, but not having much luck right now) 2. Since the problem seems to go away if we're not in a transaction, is there a way that I can issue read-only queries outside of a transaction? Thanks, Percy On Tue, Dec 18, 2012 at 6:30 AM, Percy Wegmann <percy@clicksecurity.com>wrote:
Hi Babis,
Thanks for that link! Unfortunately, I think I'm seeing a different problem, since I'm not actually doing any DDL. I found that the SQL state I'm getting is 2D000, which seems to correspond to an error in calling mvc_commit(). Time to debug!
Thank You, Percy
On Tue, Dec 18, 2012 at 3:48 AM, Charalampos Nikolaou <charnik@di.uoa.gr>wrote:
Hi Percy,
we had a similar problem with prepared statements in the past and since I saw in your bug report that the problem occurs when you are using prepared statements, then it might be related to yours. The problem was that we were creating a prepared statement, then doing an update on the database schema, and then executing the prepared statement. The second step (the update of the database schema) drops any identifiers created for keeping references to prepared statements.
The answer of Fabian to this may be found at http://mail.monetdb.org/pipermail/users-list/2012-February/005417.html.
Hope that helps, Babis
Dear MonetDB Team,
We're starting to exercise our MonetDB installation more heavily now and I've run into a strange issue where I get an occasional "COMMIT: failed" message.
It seems that the conditions required to produce this are:
- Concurrently inserting into two different tables - At the same time, issuing a SELECT COUNT(*) against either of those
On Tue, Dec 18, 2012 at 12:59 AM, Percy Wegmann <percy@clicksecurity.com> wrote: tables
I've logged a bug with more detailed information, including a Java test case:
http://bugs.monetdb.org/show_bug.cgi?id=3210
I'm only just starting my investigation, but I suspect that COUNT(*)
the culprit, since other selects like SELECT * don't seem to have this problem.
Does this ring any bells? Are there any special optimizations for COUNT(*) that bypass the underlying BAT and/or have side effects on some shared
may be table
somewhere that could be causing a concurrency violation?
Thanks,
--
Percy Wegmann +1 512 637 8500 ext 148
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
--
Percy Wegmann +1 512 637 8500 ext 148
-- Percy Wegmann +1 512 637 8500 ext 148 _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
So, I've found a workaround that seems to do the trick: - Set auto commit to false before running query - and Roll back the transaction after querying Cheers, Percy On Wed, Dec 19, 2012 at 1:28 PM, Percy Wegmann <percy@clicksecurity.com>wrote:
Okay, I've traced this to the bind_col function in bat_storage.c. It turns out that this happens with any SELECT, I was probably just more likely to see it on a SELECT COUNT because that accessed more rows.
bind_col calls bind_ucol which will update the rtime of the column if there is a transaction in progress and the access level is RD_UPD. I added some debug logging and found that:
- Running a SELECT COUNT(*) causes bind_col to be called for the first column in the table - SELECT * causes bind_col to be called for all columns in the table - In both cases, update_col is called multiple times for each column, at least one of which is called with access = RD_UPD
This raises the following questions:
1. What about doing a select causes bind_col to be called with access = RD_UPD (I'm debugging to find this, but not having much luck right now)
2. Since the problem seems to go away if we're not in a transaction, is there a way that I can issue read-only queries outside of a transaction?
Thanks, Percy
On Tue, Dec 18, 2012 at 6:30 AM, Percy Wegmann <percy@clicksecurity.com>wrote:
Hi Babis,
Thanks for that link! Unfortunately, I think I'm seeing a different problem, since I'm not actually doing any DDL. I found that the SQL state I'm getting is 2D000, which seems to correspond to an error in calling mvc_commit(). Time to debug!
Thank You, Percy
On Tue, Dec 18, 2012 at 3:48 AM, Charalampos Nikolaou <charnik@di.uoa.gr>wrote:
Hi Percy,
we had a similar problem with prepared statements in the past and since I saw in your bug report that the problem occurs when you are using prepared statements, then it might be related to yours. The problem was that we were creating a prepared statement, then doing an update on the database schema, and then executing the prepared statement. The second step (the update of the database schema) drops any identifiers created for keeping references to prepared statements.
The answer of Fabian to this may be found at http://mail.monetdb.org/pipermail/users-list/2012-February/005417.html.
Hope that helps, Babis
Dear MonetDB Team,
We're starting to exercise our MonetDB installation more heavily now and I've run into a strange issue where I get an occasional "COMMIT: failed" message.
It seems that the conditions required to produce this are:
- Concurrently inserting into two different tables - At the same time, issuing a SELECT COUNT(*) against either of those
On Tue, Dec 18, 2012 at 12:59 AM, Percy Wegmann <percy@clicksecurity.com> wrote: tables
I've logged a bug with more detailed information, including a Java test case:
http://bugs.monetdb.org/show_bug.cgi?id=3210
I'm only just starting my investigation, but I suspect that COUNT(*)
the culprit, since other selects like SELECT * don't seem to have this problem.
Does this ring any bells? Are there any special optimizations for COUNT(*) that bypass the underlying BAT and/or have side effects on some shared
may be table
somewhere that could be causing a concurrency violation?
Thanks,
--
Percy Wegmann +1 512 637 8500 ext 148
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
--
Percy Wegmann +1 512 637 8500 ext 148
--
Percy Wegmann +1 512 637 8500 ext 148
-- Percy Wegmann +1 512 637 8500 ext 148 _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
On Wed, Dec 19, 2012 at 04:25:58PM -0600, Percy Wegmann wrote:
So, I've found a workaround that seems to do the trick:
- Set auto commit to false before running query - and Roll back the transaction after querying Percy
That indeed shoulds like a possible workaround. We will continue to search why a 'read only' query set write flags in the transaction and therefor causes the transaction failure (in the insert query). Niels
Cheers, Percy
On Wed, Dec 19, 2012 at 1:28 PM, Percy Wegmann <percy@clicksecurity.com
wrote:
Okay, I've traced this to the bind_col function in bat_storage.c. It turns out that this happens with any SELECT, I was probably just more likely to see it on a SELECT COUNT because that accessed more rows.
bind_col calls bind_ucol which will update the rtime of the column if there is a transaction in progress and the access level is RD_UPD. I added some debug logging and found that:
- Running a SELECT COUNT(*) causes bind_col to be called for the first column in the table - SELECT * causes bind_col to be called for all columns in the table - In both cases, update_col is called multiple times for each column, at least one of which is called with access = RD_UPD
This raises the following questions:
1. What about doing a select causes bind_col to be called with access = RD_UPD (I'm debugging to find this, but not having much luck right now)
2. Since the problem seems to go away if we're not in a transaction, is there a way that I can issue read-only queries outside of a transaction?
Thanks, Percy
On Tue, Dec 18, 2012 at 6:30 AM, Percy Wegmann < percy@clicksecurity.com> wrote:
Hi Babis,
Thanks for that link! Unfortunately, I think I'm seeing a different problem, since I'm not actually doing any DDL. I found that the SQL state I'm getting is 2D000, which seems to correspond to an error in calling mvc_commit(). Time to debug!
Thank You, Percy
On Tue, Dec 18, 2012 at 3:48 AM, Charalampos Nikolaou < charnik@di.uoa.gr> wrote:
Hi Percy,
we had a similar problem with prepared statements in the past and since I saw in your bug report that the problem occurs when you are using prepared statements, then it might be related to yours. The problem was that we were creating a prepared statement, then doing an update on the database schema, and then executing the prepared statement. The second step (the update of the database schema) drops any identifiers created for keeping references to prepared statements.
The answer of Fabian to this may be found at http://mail.monetdb.org/pipermail/users-list/2012-February/ 005417.html.
Hope that helps, Babis
On Tue, Dec 18, 2012 at 12:59 AM, Percy Wegmann < percy@clicksecurity.com> wrote: > Dear MonetDB Team, > > We're starting to exercise our MonetDB installation more heavily now and > I've run into a strange issue where I get an occasional "COMMIT: failed" > message. > > It seems that the conditions required to produce this are: > > - Concurrently inserting into two different tables > - At the same time, issuing a SELECT COUNT(*) against either of those tables > > I've logged a bug with more detailed information, including a Java test > case: > > http://bugs.monetdb.org/show_bug.cgi?id=3210 > > I'm only just starting my investigation, but I suspect that COUNT(*) may be > the culprit, since other selects like SELECT * don't seem to have this > problem. > > Does this ring any bells? Are there any special optimizations for COUNT(*) > that bypass the underlying BAT and/or have side effects on some shared table > somewhere that could be causing a concurrency violation? > > Thanks, > > -- > > Percy Wegmann > +1 512 637 8500 ext 148 > > > _______________________________________________ > users-list mailing list > users-list@monetdb.org > http://mail.monetdb.org/mailman/listinfo/users-list > _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
--
Percy Wegmann +1 512 637 8500 ext 148
--
Percy Wegmann +1 512 637 8500 ext 148
--
Percy Wegmann +1 512 637 8500 ext 148
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
-- Niels Nes, Centrum Wiskunde & Informatica (CWI) Science Park 123, 1098 XG Amsterdam, The Netherlands room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
On Mon, Dec 17, 2012 at 04:59:03PM -0600, Percy Wegmann wrote:
Dear MonetDB Team,
We're starting to exercise our MonetDB installation more heavily now and I've run into a strange issue where I get an occasional "COMMIT: failed" message.
It seems that the conditions required to produce this are:
- Concurrently inserting into two different tables - At the same time, issuing a SELECT COUNT(*) against either of those tables
I've logged a bug with more detailed information, including a Java test case:
http://bugs.monetdb.org/show_bug.cgi?id=3210
I'm only just starting my investigation, but I suspect that COUNT(*) may be the culprit, since other selects like SELECT * don't seem to have this problem.
Does this ring any bells? Are there any special optimizations for COUNT(*) that bypass the underlying BAT and/or have side effects on some shared table somewhere that could be causing a concurrency violation?
Thanks,
Percy We fixed a problem today which looks very similar too yours. Could you verify if the fixes checked in to the Oct2012 and Feb2013 branches also solve your problem? Niels
--
Percy Wegmann +1 512 637 8500 ext 148
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
-- Niels Nes, Centrum Wiskunde & Informatica (CWI) Science Park 123, 1098 XG Amsterdam, The Netherlands room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
Hi Niels, I will do that. It might be a few days before I get to this as we're in the middle of testing with the SP2 release, but I'll definitely get around to it. Thanks! Percy On Mon, Jan 7, 2013 at 8:44 AM, Niels Nes <Niels.Nes@cwi.nl> wrote:
On Mon, Dec 17, 2012 at 04:59:03PM -0600, Percy Wegmann wrote:
Dear MonetDB Team,
We're starting to exercise our MonetDB installation more heavily now and I've run into a strange issue where I get an occasional "COMMIT: failed" message.
It seems that the conditions required to produce this are:
- Concurrently inserting into two different tables - At the same time, issuing a SELECT COUNT(*) against either of those tables
I've logged a bug with more detailed information, including a Java test case:
http://bugs.monetdb.org/show_bug.cgi?id=3210
I'm only just starting my investigation, but I suspect that COUNT(*) may be the culprit, since other selects like SELECT * don't seem to have this problem.
Does this ring any bells? Are there any special optimizations for COUNT(*) that bypass the underlying BAT and/or have side effects on some shared table somewhere that could be causing a concurrency violation?
Thanks,
Percy
We fixed a problem today which looks very similar too yours. Could you verify if the fixes checked in to the Oct2012 and Feb2013 branches also solve your problem?
Niels
--
Percy Wegmann +1 512 637 8500 ext 148
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
-- Niels Nes, Centrum Wiskunde & Informatica (CWI) Science Park 123, 1098 XG Amsterdam, The Netherlands room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
-- Percy Wegmann +1 512 637 8500 ext 148 _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
Hi Niels, Sorry about the delay. I grabbed the code from the the Oct2012 branch in mercurial, built it and ran the test from http://bugs.monetdb.org/show_bug.cgi?id=3210. mserver5 shows a version of 11.13.8. Sadly, it still fails occasionally. It might be failing less frequently than before, but that's just anecdotal - it's always been non-deterministic and I haven't run it often enough to come up with a statistically significant result. Thanks, Percy On Mon, Jan 7, 2013 at 8:49 AM, Percy Wegmann <percy@clicksecurity.com>wrote:
Hi Niels,
I will do that. It might be a few days before I get to this as we're in the middle of testing with the SP2 release, but I'll definitely get around to it.
Thanks! Percy
On Mon, Jan 7, 2013 at 8:44 AM, Niels Nes <Niels.Nes@cwi.nl> wrote:
On Mon, Dec 17, 2012 at 04:59:03PM -0600, Percy Wegmann wrote:
Dear MonetDB Team,
We're starting to exercise our MonetDB installation more heavily now and I've run into a strange issue where I get an occasional "COMMIT: failed" message.
It seems that the conditions required to produce this are:
- Concurrently inserting into two different tables - At the same time, issuing a SELECT COUNT(*) against either of those tables
I've logged a bug with more detailed information, including a Java test case:
http://bugs.monetdb.org/show_bug.cgi?id=3210
I'm only just starting my investigation, but I suspect that COUNT(*) may be the culprit, since other selects like SELECT * don't seem to have this problem.
Does this ring any bells? Are there any special optimizations for COUNT(*) that bypass the underlying BAT and/or have side effects on some shared table somewhere that could be causing a concurrency violation?
Thanks,
Percy
We fixed a problem today which looks very similar too yours. Could you verify if the fixes checked in to the Oct2012 and Feb2013 branches also solve your problem?
Niels
--
Percy Wegmann +1 512 637 8500 ext 148
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
-- Niels Nes, Centrum Wiskunde & Informatica (CWI) Science Park 123, 1098 XG Amsterdam, The Netherlands room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
--
Percy Wegmann +1 512 637 8500 ext 148
-- Percy Wegmann +1 512 637 8500 ext 148 _______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
On Mon, Jan 14, 2013 at 04:58:24PM -0600, Percy Wegmann wrote:
Hi Niels,
Sorry about the delay. I grabbed the code from the the Oct2012 branch in mercurial, built it and ran the test from http://bugs.monetdb.org/ show_bug.cgi?id=3210. mserver5 shows a version of 11.13.8.
Sadly, it still fails occasionally. It might be failing less frequently than before, but that's just anecdotal - it's always been non-deterministic and I haven't run it often enough to come up with a statistically significant result.
Last week we fixed another, (even) less frequent problem. Hopefully this also solve your concurrency problems. Niels
Thanks, Percy
On Mon, Jan 7, 2013 at 8:49 AM, Percy Wegmann <percy@clicksecurity.com> wrote:
Hi Niels,
I will do that. It might be a few days before I get to this as we're in the middle of testing with the SP2 release, but I'll definitely get around to it.
Thanks! Percy
On Mon, Jan 7, 2013 at 8:44 AM, Niels Nes <Niels.Nes@cwi.nl> wrote:
On Mon, Dec 17, 2012 at 04:59:03PM -0600, Percy Wegmann wrote: > Dear MonetDB Team, > > We're starting to exercise our MonetDB installation more heavily now > and I've run into a strange issue where I get an occasional "COMMIT: > failed" message. > > It seems that the conditions required to produce this are: > > - Concurrently inserting into two different tables > - At the same time, issuing a SELECT COUNT(*) against either of those > tables > > I've logged a bug with more detailed information, including a Java test > case: > > http://bugs.monetdb.org/show_bug.cgi?id=3210 > > I'm only just starting my investigation, but I suspect that COUNT(*) > may be the culprit, since other selects like SELECT * don't seem to > have this problem. > > Does this ring any bells? Are there any special optimizations for > COUNT(*) that bypass the underlying BAT and/or have side effects on > some shared table somewhere that could be causing a concurrency > violation? > > Thanks,
Percy
We fixed a problem today which looks very similar too yours. Could you verify if the fixes checked in to the Oct2012 and Feb2013 branches also solve your problem?
Niels > > -- > > Percy Wegmann > +1 512 637 8500 ext 148 >
> _______________________________________________ > users-list mailing list > users-list@monetdb.org > http://mail.monetdb.org/mailman/listinfo/users-list
-- Niels Nes, Centrum Wiskunde & Informatica (CWI) Science Park 123, 1098 XG Amsterdam, The Netherlands room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
--
Percy Wegmann +1 512 637 8500 ext 148
--
Percy Wegmann +1 512 637 8500 ext 148
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
-- Niels Nes, Centrum Wiskunde & Informatica (CWI) Science Park 123, 1098 XG Amsterdam, The Netherlands room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
Cool! Which branch/tag should I be looking at? Thanks, Percy On Mon, Jan 28, 2013 at 12:30 PM, Niels Nes <Niels.Nes@cwi.nl> wrote:
On Mon, Jan 14, 2013 at 04:58:24PM -0600, Percy Wegmann wrote:
Hi Niels,
Sorry about the delay. I grabbed the code from the the Oct2012 branch in mercurial, built it and ran the test from http://bugs.monetdb.org/ show_bug.cgi?id=3210. mserver5 shows a version of 11.13.8.
Sadly, it still fails occasionally. It might be failing less frequently than before, but that's just anecdotal - it's always been non-deterministic and I haven't run it often enough to come up with a statistically significant result.
Last week we fixed another, (even) less frequent problem. Hopefully this also solve your concurrency problems.
Niels
Thanks, Percy
On Mon, Jan 7, 2013 at 8:49 AM, Percy Wegmann <percy@clicksecurity.com> wrote:
Hi Niels,
I will do that. It might be a few days before I get to this as we're in the middle of testing with the SP2 release, but I'll definitely get around to it.
Thanks! Percy
On Mon, Jan 7, 2013 at 8:44 AM, Niels Nes <Niels.Nes@cwi.nl> wrote:
On Mon, Dec 17, 2012 at 04:59:03PM -0600, Percy Wegmann wrote: > Dear MonetDB Team, > > We're starting to exercise our MonetDB installation more heavily now > and I've run into a strange issue where I get an occasional "COMMIT: > failed" message. > > It seems that the conditions required to produce this are: > > - Concurrently inserting into two different tables > - At the same time, issuing a SELECT COUNT(*) against either of those > tables > > I've logged a bug with more detailed information, including a Java test > case: > > http://bugs.monetdb.org/show_bug.cgi?id=3210 > > I'm only just starting my investigation, but I suspect that COUNT(*) > may be the culprit, since other selects like SELECT * don't seem to > have this problem. > > Does this ring any bells? Are there any special optimizations for > COUNT(*) that bypass the underlying BAT and/or have side effects on > some shared table somewhere that could be causing a concurrency > violation? > > Thanks,
Percy
We fixed a problem today which looks very similar too yours. Could you verify if the fixes checked in to the Oct2012 and Feb2013 branches also solve your problem?
Niels > > -- > > Percy Wegmann > +1 512 637 8500 ext 148 >
> _______________________________________________ > users-list mailing list > users-list@monetdb.org > http://mail.monetdb.org/mailman/listinfo/users-list
-- Niels Nes, Centrum Wiskunde & Informatica (CWI) Science Park 123, 1098 XG Amsterdam, The Netherlands room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
--
Percy Wegmann +1 512 637 8500 ext 148
--
Percy Wegmann +1 512 637 8500 ext 148
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
-- Niels Nes, Centrum Wiskunde & Informatica (CWI) Science Park 123, 1098 XG Amsterdam, The Netherlands room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
-- Percy Wegmann +1 512 637 8500 ext 148
On Mon, Jan 28, 2013 at 12:46:31PM -0600, Percy Wegmann wrote:
Cool! Which branch/tag should I be looking at? Fixes where checked in on all branches, ie Oct2012, Feb2013 and default.
Niels
Thanks, Percy
On Mon, Jan 28, 2013 at 12:30 PM, Niels Nes <Niels.Nes@cwi.nl> wrote:
On Mon, Jan 14, 2013 at 04:58:24PM -0600, Percy Wegmann wrote: > Hi Niels, > > Sorry about the delay. I grabbed the code from the the Oct2012 branch > in mercurial, built it and ran the test from http:// bugs.monetdb.org/ > show_bug.cgi?id=3210. mserver5 shows a version of 11.13.8. > > Sadly, it still fails occasionally. It might be failing less > frequently than before, but that's just anecdotal - it's always been > non-deterministic and I haven't run it often enough to come up with a > statistically significant result.
Last week we fixed another, (even) less frequent problem. Hopefully this also solve your concurrency problems.
Niels > > Thanks, > Percy > > > On Mon, Jan 7, 2013 at 8:49 AM, Percy Wegmann < percy@clicksecurity.com> > wrote: > > Hi Niels, > > I will do that. It might be a few days before I get to this as > we're in the middle of testing with the SP2 release, but I'll > definitely get around to it. > > Thanks! > Percy > > > On Mon, Jan 7, 2013 at 8:44 AM, Niels Nes <Niels.Nes@cwi.nl> wrote: > > On Mon, Dec 17, 2012 at 04:59:03PM -0600, Percy Wegmann wrote: > > Dear MonetDB Team, > > > > We're starting to exercise our MonetDB installation more > heavily now > > and I've run into a strange issue where I get an occasional > "COMMIT: > > failed" message. > > > > It seems that the conditions required to produce this are: > > > > - Concurrently inserting into two different tables > > - At the same time, issuing a SELECT COUNT(*) against either > of those > > tables > > > > I've logged a bug with more detailed information, including a > Java test > > case: > > > > http://bugs.monetdb.org/show_bug.cgi?id=3210 > > > > I'm only just starting my investigation, but I suspect that > COUNT(*) > > may be the culprit, since other selects like SELECT * don't > seem to > > have this problem. > > > > Does this ring any bells? Are there any special > optimizations for > > COUNT(*) that bypass the underlying BAT and/or have side > effects on > > some shared table somewhere that could be causing a > concurrency > > violation? > > > > Thanks, > > Percy > > We fixed a problem today which looks very similar too yours. > Could you > verify if the fixes checked in to the Oct2012 and Feb2013 > branches also > solve your problem? > > Niels > > > > -- > > > > Percy Wegmann > > +1 512 637 8500 ext 148 > > > > > _______________________________________________ > > users-list mailing list > > users-list@monetdb.org > > http://mail.monetdb.org/mailman/listinfo/users-list > > > -- > Niels Nes, Centrum Wiskunde & Informatica (CWI) > Science Park 123, 1098 XG Amsterdam, The Netherlands > room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl > url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl > > _______________________________________________ > users-list mailing list > users-list@monetdb.org > http://mail.monetdb.org/mailman/listinfo/users-list > > > > > > -- > > Percy Wegmann > +1 512 637 8500 ext 148 > > > > > -- > > Percy Wegmann > +1 512 637 8500 ext 148
> _______________________________________________ > users-list mailing list > users-list@monetdb.org > http://mail.monetdb.org/mailman/listinfo/users-list
-- Niels Nes, Centrum Wiskunde & Informatica (CWI) Science Park 123, 1098 XG Amsterdam, The Netherlands room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
--
Percy Wegmann +1 512 637 8500 ext 148
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
-- Niels Nes, Centrum Wiskunde & Informatica (CWI) Science Park 123, 1098 XG Amsterdam, The Netherlands room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
participants (3)
-
Charalampos Nikolaou -
Niels Nes -
Percy Wegmann