Hi Emmanuel,
We ran into the same issue again last night. I actually missed out part mentioning in yesterday's response, we do indeed use transactions with Begin/Commit, but not on our primary application, which is where I had focused my attention. Last night, as the night before where I was misguided to what I thought the problem was, it was in fact our Web application tier, which is a Hibernate implementation which uses the c3p0 JDBC pool implementation. Is there any known issues for c3p0 and Sequoia? We did see this also last night 2008-05-21 01:45:08,483 WARN sequoia.controller.recoverylog Recovery log is dirty. Clearing. Please use restore log Currently our automated script, will take an image, and then purge the log from the image taken 3 days ago, so the above could have been related to anything from the 3 days prior. 2008-05-21 01:49:48,599 WARN sequoia.controller.scheduler Timeout in begin, still waiting for 0 pending transactions to complete 2008-05-21 01:49:48,599 WARN controller.virtualdatabase.XXXX Begin failed (Timeout in begin, still waiting for 0 pending transactions to complete) 2008-05-21 01:49:48,599 INFO virtualdatabase.VirtualDatabaseWorkerThread.XXXX Error during command execution (Timeout in begin, still waiting for 0 pending transactions to complete) For me to fix this last night, I had to disable our web application servers from accessing the Sequoia cluster (not our primary application which does not use transactions) as a result of doing this the pg_dump started up. My question is, now that I know it is related to these web applications, which are using proper transactions, is it possible there is a begin without a commit / rollback in the recovery log, and if so is this why the sequoia is telling me it is a dirty recovery log as I had to manually shut those web applications down to release the lock on the transaction? If this is true, is there a potential that there is a pending open transaction from one of the web applications? I would try to tie that up based on our recovery log, but it was purged as a result of Sequoia claiming it was dirty. Would the same occur if we had just done a disable on the backend ? Regards, Stuart _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
