Hannes,

That GDK error is an issue that keeps popping up since we switched to Oct2014 (never occurred in Feb2013) and is definitely related to / triggered from concurrency.

Unfortunately it is really hard to make it reproducible for others, as it happens at the end of a long ETL process, and not all the time.

The best I could do is to provide a gdb session ready where the error occurs. But I doubt there is a problem where the error occurs, it seems it simply stops there because at some previous moment data corruption occurred.

So, really hard to debug.

It seems related to this https://www.monetdb.org/bugzilla/show_bug.cgi?id=3450 (as I had commented last year). The bug is marked as fixed, though I don't see any detail about the fix.

Roberto

On 29 April 2015 at 17:50, Hannes Mühleisen <Hannes.Muehleisen@cwi.nl> wrote:

Hi,

> On 29 Apr 2015, at 17:39, Bryan Senseman <monetdb@openbi.com> wrote:
>
> However, it is not transaction-safe. When I use this method, and some SQL transaction happens to read (only read!) from the same tables at the same time, then I often get data corruption: the COPY INTO seems to end well (and the data gets actually in place), but new SQL queries on those tables fail with a "BATproject: does not match always" GDK error (checking with gdb I see that the right side of a fetchjoin has count 0).

If this is an issue and you can reproduce it, could you please file a bug report. This should not happen.

Hannes

_______________________________________________
users-list mailing list
users-list@monetdb.org
https://www.monetdb.org/mailman/listinfo/users-list