Hello, (sorry my english, google translate) When I drop tables that does not exist, the drop may remain in queue. sql>DROP TABLE ci__data__agregats ; DROP TABLE ci__data__reporting ;DROP TABLE ci__data__reporting_ci ; DROP TABLE ci__data__reporting_regle; DROP TABLE ci__data__resultats; DROP TABLE ci__data__resultats_datamart; DROP TABLE ci__data__traductions; DROP TABLE ci__ref__calcul_final; DROP TABLE ci__ref__traductions_agregats; DROP TABLE src__arv__achat; DROP TABLE src__bil__commandes; DROP TABLE src__eve__abo; DROP TABLE src__eve__qlf; DROP TABLE src__eve__vpc; DROP TABLE src__mia__inscrits; DROP TABLE src__sdv__inscrits; operation successful (28.442ms) DROP TABLE: no such table 'ci__data__reporting' DROP TABLE: no such table 'ci__data__reporting_ci' DROP TABLE: no such table 'ci__data__reporting_regle' operation successful (28.490ms) operation successful (28.497ms) operation successful (28.502ms) operation successful (28.507ms) operation successful (28.511ms) DROP TABLE: no such table 'src__arv__achat' DROP TABLE: no such table 'src__bil__commandes' DROP TABLE: no such table 'src__eve__abo' DROP TABLE: no such table 'src__eve__qlf' DROP TABLE: no such table 'src__eve__vpc' DROP TABLE: no such table 'src__mia__inscrits' DROP TABLE: no such table 'src__sdv__inscrits' sql>select * from sys.queue(); +------+---------+----------------------------+----------------------------+----------+---------+-------------------+---------------------------------+ | qtag | user | started | estimate | progress | status | tag | query | +======+=========+============================+============================+==========+=========+===================+=================================+ | 12 | monetdb | 2014-10-17 14:34:16.000000 | 2014-10-17 14:34:16.024000 | null | running | 51539607560@0 | drop table src__arv__achat; | | 13 | monetdb | 2014-10-17 14:34:16.000000 | 6453-11-03 00:20:26.928000 | null | running | 140082976780320@0 | drop table src__bil__commandes; | | 14 | monetdb | 2014-10-17 14:34:16.000000 | null | null | running | 4@0 | drop table src__eve__abo; | | 15 | monetdb | 2014-10-17 14:34:23.000000 | null | null | running | 11776651@0 | select * from sys.queue(); | +------+---------+----------------------------+----------------------------+----------+---------+-------------------+---------------------------------+ 4 tuples (1.504ms) We do a lot of drop followed by create table. We believe that this is related to a concern for duplication in the catalog table ( table xxx is not single , corrupt catalog ? ) Pierre -- 1G6 52 route de bischwiller 67300 Schiltigheim Société de Services et de Formations en Logiciels Libres http://1g6.biz Tél : 06 64 63 70 35
I have installed MonetDB and and started using it through MAPI. The documentation indicates that opening multiple connections from separate threads in a single process is supported. I perused the MAPI source and it appears that all of the Monet data structures used are associated with the connection. In our application the threads will be independent and processing similar but unique data sets each with its own connection to the database. No threads will share a database connection nor attempt to use another threads connection. Does anyone have experience using multiple threads in a single process each accessing a separate database MonetDB MAPI connection they would like to share? Did you have any problems? Doug Service
Hello Bug acknowledged and fixed in Oct2014 branch. thanks for reporting, Martin On 17/10/14 16:44, Pierre-Adrien Coustillas wrote:
Hello, (sorry my english, google translate)
When I drop tables that does not exist, the drop may remain in queue.
sql>DROP TABLE ci__data__agregats ; DROP TABLE ci__data__reporting ;DROP TABLE ci__data__reporting_ci ; DROP TABLE ci__data__reporting_regle; DROP TABLE ci__data__resultats; DROP TABLE ci__data__resultats_datamart; DROP TABLE ci__data__traductions; DROP TABLE ci__ref__calcul_final; DROP TABLE ci__ref__traductions_agregats; DROP TABLE src__arv__achat; DROP TABLE src__bil__commandes; DROP TABLE src__eve__abo; DROP TABLE src__eve__qlf; DROP TABLE src__eve__vpc; DROP TABLE src__mia__inscrits; DROP TABLE src__sdv__inscrits; operation successful (28.442ms) DROP TABLE: no such table 'ci__data__reporting' DROP TABLE: no such table 'ci__data__reporting_ci' DROP TABLE: no such table 'ci__data__reporting_regle' operation successful (28.490ms) operation successful (28.497ms) operation successful (28.502ms) operation successful (28.507ms) operation successful (28.511ms) *DROP TABLE: no such table 'src__arv__achat'* *DROP TABLE: no such table 'src__bil__commandes'* *DROP TABLE: no such table 'src__eve__abo'* DROP TABLE: no such table 'src__eve__qlf' DROP TABLE: no such table 'src__eve__vpc' DROP TABLE: no such table 'src__mia__inscrits' DROP TABLE: no such table 'src__sdv__inscrits'
sql>select * from sys.queue(); +------+---------+----------------------------+----------------------------+----------+---------+-------------------+---------------------------------+ | qtag | user | started | estimate | progress | status | tag | query | +======+=========+============================+============================+==========+=========+===================+=================================+ | 12 | monetdb | 2014-10-17 14:34:16.000000 | 2014-10-17 14:34:16.024000 | null | running | 51539607560@0 | drop table src__arv__achat; | | 13 | monetdb | 2014-10-17 14:34:16.000000 | 6453-11-03 00:20:26.928000 | null | running | 140082976780320@0 | drop table src__bil__commandes; | | 14 | monetdb | 2014-10-17 14:34:16.000000 | null | null | running | 4@0 | drop table src__eve__abo; | | 15 | monetdb | 2014-10-17 14:34:23.000000 | null | null | running | 11776651@0 | select * from sys.queue(); | +------+---------+----------------------------+----------------------------+----------+---------+-------------------+---------------------------------+ 4 tuples (1.504ms)
We do a lot of drop followed by create table. We believe that this is related to a concern for duplication in the catalog table (table xxx is not single, corrupt catalog?)
Pierre
-- 1G6 52 route de bischwiller 67300 Schiltigheim Société de Services et de Formations en Logiciels Libres http://1g6.biz Tél : 06 64 63 70 35
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
participants (3)
-
Doug Service -
Martin Kersten -
Pierre-Adrien Coustillas