Closed jrehmer closed 11 months ago
Having discussed about this with Bo Lindbergh, the author of ovsqlite, he suggests to raise the busy timeout value. The DBD::SQLite default is 30 seconds, and can be set in ovsqlite-util
to the same (huge) number of milliseconds that ovsqlite-server
itself uses.
Just add this line in ovsqlite-util
:
# To process multiple SQL statements in a do() handle.
$dbh->{sqlite_allow_multiple_statements} = 1;
+$dbh->sqlite_busy_timeout(999999999);
+
# Check the specified newsgroup exists, and create appropriate SQL requests.
I hope it will fix the problem you encounter... and also that ovsqlite-util
won't be running for 3 days! (Though you're now accustomed to long-running programs like makehistory
;-))
Incidentally, is your transtimelimit
setting in ovsqlite.conf at 10.0 seconds (the default)?
Right now I have transtimelimit
set to 10, but at the time I made this report it was likely at 100 from when I was running makehistory
.
I've tried to replicate this today and cannot, which makes sense with the lower transaction time limit on the server and the 30 second timeout from the client library.
I am waiting for a long running innxmit
process to complete that is moving my current tradspool contents to a new server with CNFS. I chose not to have INN build overview during the initial seed of the new server, so I will be running makehistory
after innxmit
completes. I should be able to replicate it during that process and test the patch.
OK, thanks for your answer confirming that transtimelimit
had been changed.
I believe this issue is now fixed by that patch. Naturally, feel free to reopen it or leave a comment if it happens you're still seeing it.
There have been cases where I am unable to run ovsqlite-util and receive the following error:
This occurs frequently on a busy server. I don't know if checking for this error and re-trying or other methods of checking/waiting for a lock to be released can be implemented, but seems feasible.