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




--

Percy Wegmann
+1 512 637 8500 ext 148