Database lockup - regular but intermittent

[jed@…]

I am unable to logon to Trac. I get the error message shown below. If you believe it is a server issue please let me know. This problem has occurred about 5 times in the last 10 minutes. But seems to be an intermittent issue. I am fine when I go to the main page: ​https://develop.participatoryculture.org/trac/democracy/

However when I try to do anything like ​https://develop.participatoryculture.org/trac/democracy/query?status=new&milestone=Unassigned&order=id&desc=1 I get the error.

Python Traceback

Traceback (most recent call last):
  File "/usr/lib64/python2.4/site-packages/trac/web/main.py", line 387, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib64/python2.4/site-packages/trac/web/main.py", line 192, in dispatch
    req.session = Session(self.env, req)
  File "/usr/lib64/python2.4/site-packages/trac/web/session.py", line 52, in __init__
    self.promote_session(sid)
  File "/usr/lib64/python2.4/site-packages/trac/web/session.py", line 154, in promote_session
    db.commit()
OperationalError: database is locked

[Emmanuel Blot]

The site reports "Powered by Trac 0.10.2 By Edgewall Software." - not 0.10.3

[Emmanuel Blot]

Please ask the site administrator to upgrade to 0.10.3.

See also #4401.

[anonymous]

Our administrator updated our Trac system to 0.10.3 and I and a number of other people are still having issues using Trac. In general I get a message that state the Database is Locked when I try to query or update tickets.

[emsearcy]

Yes, the upgrade unfortunately did not resolve the problem. The database in question is sqlite, the system is running on Apache 2.0+mod_python.

While typing this, I believe I have discovered why, though:

The DB is *very* large (with plenty of open tickets ;-). Whereas I had doctored up the reports in the past so that they did not pull in the entire ticket under the hidden/RSS field _description (I encountered this awhile ago, but the symptom then for a report failure was a timeout in the web browser, not a Trac fatal error), I cannot do a similar fix to the query page.

Why is this a database locked' error? Why not a database timeout out' or query result too large'? Or, perhaps the query page should have the very-useful Show n results starting at result n' type of option?

[Emmanuel Blot]

Please do not tamper w/ the ticket status without explaining the reason about your change.

[Christian Boos]

The site seems to be quite responsive - are you still experiencing locks?

[anonymous]

Replying to cboos:

The site seems to be quite responsive - are you still experiencing locks?

If you go to the original poster's link (Custom Query page), there is now a checkbox with the text 'Show full description under each result' that did not used to be there, IIRC. Previously, the default action was to show the full description. If you *do* check this box, the page returns a 500 Internal Server Error.

I am positive that this is because the result of the DB query is enormous. It *would* be nice if Trac could handle a 'DB query result too big' problem rather than causing an error page.

However, I do not administer that web site any longer and am not concerned about this specific problem, and so am removing myself from the CC.

[Christian Boos]

Ok, thanks for the precision.

The problem doesn't seem to be related to a huge query (though it seems to be the norm there to include huge logs in ticket descriptions), rather some problematic content.

I narrowed it down to 3 tickets that are extremely slow to load:

• #5540
• #5891
• #5331

the latter alone always triggering a 500.

It would be extremely useful to get access to the source of this ticket…

[Christian Boos]

See #3944.