Hi Markus,
after reading some more about postgres transaction semantics I'm sure
again that it is the 'sequoiasabase' which causes the transaction to
abort. Any query inside a transaction block which results in an error
will abort the transaction till rollback or commit. Since the
'sequoiasabase' call result in an error the current transaction is
aborted, and since activemq does not use savepoints there is no point to
recover the transaction.
How to I disable the 'sequoiasabase' call?
The sequoiasabase call cannot be disabled and it is only a check for
additional semantic information when fetching the database schema. So
this message is not an error like a request failing, it is just that
this table cannot be found and semantic information will not be used
(anyway this is a disabled prototype in 2.10 but the message was not
cleaned up). You can create an empty sequoiasabase table if you want but
you can safely ignore this. I don't remember calls to metadata causing
transaction aborts with Postgres.
As soon as one create statement fails in a transaction, Postgres will
rollback the transaction and you have to explicitly rollback the
transaction if you want to continue. You can check the existence of a
table using prior creating it using the getTables() call or use a
'create if exist' like syntax.
If the creation only fails on 1 backend it means that your backends have
different schemas and are not synchronized anymore.
What happens if you perform the 'create table' and 'create index' in 2
separate transactions, does it work?
Thanks for your feedback,
Emmanuel
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [EMAIL PROTECTED]
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
