Yes, it IMHO is: an extract of you serial log reveals: ======== [...] CREATE INDEX hash_values_value_idx ON hash_values (value); PREPARE SELECT MAX(id), MOD((id >> 28) + 16, 16) AS grp FROM hash_values GROUP BY grp; -- 1st PREPARE -> ID "0" exec 0(); CREATE TABLE namespace_prefixes ( prefix VARCHAR(127), namespace TEXT NOT NULL ); -- schema update -> deletes ALL PREPAREd statements [...] PREPARE SELECT id, value FROM hash_values WHERE value IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?); -- 1st (after "reset") PREPARE -> ID "0" exec 0(14329055, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); PREPARE INSERT INTO hash_values (id, value) VALUES (?, ?); -- 2nd PREPARE -> ID "1" PREPARE INSERT INTO uri_values (id, value) VALUES (?, ?); -- 4rd PREPARE -> ID "2" exec 0(14154331, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); exec 0(142752235, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); PREPARE INSERT INTO label_values (id, value) VALUES (?, ?); -- 4th PREPARE -> ID "3" PREPARE INSERT INTO namespace_prefixes (prefix, namespace) VALUES (?, ?); -- 5th PREPARE -> ID "4" exec 2(NULL, 'http://www.recshop.fake/cd#'); PREPARE UPDATE namespace_prefixes SET prefix = ? WHERE namespace = ?; -- 6th PREPARE -> ID "5" exec 3('cd', 'http://www.recshop.fake/cd#'); PREPARE INSERT INTO namespace_prefixes (prefix, namespace) VALUES (?, ?); -- 7th PREPARE -> ID "6" exec 4(NULL, 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'); PREPARE UPDATE namespace_prefixes SET prefix = ? WHERE namespace = ?; -- 8th PREPARE -> ID "7" exec 5('rdf', 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'); CREATE TABLE triples ( ctx INTEGER NOT NULL, subj INTEGER NOT NULL, pred INTEGER NOT NULL, obj INTEGER NOT NULL, expl BOOL NOT NULL, interval_start TIMESTAMP DEFAULT NULL, interval_end TIMESTAMP DEFAULT NULL ); -- schema update -> deletes ALL PREPAREd statements [...] PREPARE INSERT INTO triples (ctx, subj, pred, obj, expl) VALUES (?, ?, ?, ?, ?); -- 1st (after "reset") PREPARE -> ID "0" exec 0(0, 1, 2, 805306369, true); exec 1(1, 14329055); -- ! ^ no such prepared statement ! exec 1(2, 14154331); exec 1(805306369, 142752235); ======== Stefan On Thu, Feb 23, 2012 at 04:20:46PM +0100, Stefan Manegold wrote:
Could this http://sourceforge.net/mailarchive/message.php?msg_id=28878164 also be the to the issue reported here?
from the link above: " Here is the problem. If you perform a schema update/change, MonetDB releases all prepared handles, because they possibly are no longer correct. You need to re-execute your prepare command. "
?
Stefan
On Mon, Apr 11, 2011 at 06:58:02PM +0300, Charalampos Nikolaou wrote:
Hi, any hint on this? Because this discussion has been dormant
Here I am again,
I have made all my interactions with the server to be auto-committed. Still I get a "current transaction abort (please rollback)" error message without understanding the reason. I have looked into the jdbc logs very carefully, I have also serialized all 6 connections, but nothing seem to be wrong. The interaction with the server is attached in sql.log (contains only the sql commands as if there was a single connection executing them). The serialized logs are attached in serial.log (there are comments about the time a connection starts/continues/ends or giving execution to another connection, and all timestamps generated from jdbc have been replaced by 1, 2, 3, and so on for readability purposes. All lines starting with % or [ have been omitted; the complete logs for each connection are also attached in monet_*.log files. All files are attached in a .zip archive.
If you can see something that I can't please report it.
Thanks a lot, Babis
------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
-- | Stefan.Manegold @ CWI.nl | DB Architectures (INS1) | | http://CWI.nl/~manegold/ | Science Park 123 (L321) | | Tel.: +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) |
------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
-- | Stefan.Manegold @ CWI.nl | DB Architectures (INS1) | | http://CWI.nl/~manegold/ | Science Park 123 (L321) | | Tel.: +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) |