Hi Neil,
But, when I run the controllers a second time, I get these
outputs:
21:12:17,869 WARN sequoia.controller.recoverylog Backend table BACKEND does
not match database table name case (backend)
This can be safely ignored. The problem is that Postgres converts the
table names in lowercase and its driver reports it as is. A conflicting
case is usually not an issue with most databases. You can change your
config file to use lowercase names instead.
We use by default uppercase because HSQL converts all table name to
uppercase by default, and HSQL is our preferred database to store the
recovery log.
The cluster log has this output:
2007-01-14 21:14:00,765 WARN backend.DatabaseBackend.cbsweb2 Unable to find
table "deleteme1168830840549" in database schema, scheduling query DROP
TABLE "DELETEME1168830840549" CASCA... in conflicting queue. Method:
getQueueAndWriteLockTables
It looks like the table case is still a problem.
There might be a problem in the DROP parser, it should be case
insensitive. Or the table does not exist anymore.
Looking at the backend database, the deleteme table is not there anymore so
it looks like
it executed.
Why would it put the query in the conflicting queue?
As the table is not found in the schema, it cannot be properly locked.
In that case, we execute requests sequentially (in the conflicting
queue) to prevent any out-of-order execution.
Thanks for your feedback,
Emmanuel
--
Emmanuel Cecchet
Chief Scientific Officer, Continuent
Blog: http://emanux.blogspot.com/
Open source: http://www.continuent.org
Corporate: http://www.continuent.com
Skype: emmanuel_cecchet
Cell: +33 687 342 685
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
