OperationalError: database or disk is full

[mrateliff@…]

How to Reproduce

While doing a GET operation on , Trac issued an internal error.

(When attempting to log in, I receive an error that the database or disk is full. Need this resolved ASAP.)

System Information

Trac	0.11.7
Python	2.5.4 (r254:67916, Dec 3 2009, 14:36:49) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)]
setuptools	0.6c11
SQLite	3.3.6
pysqlite	2.5.6
Genshi	0.6
mod_wsgi	3.4 (WSGIProcessGroup tracdaemon WSGIApplicationGroup %{GLOBAL})
Pygments	1.1.1
Agilo	py2.5
CustomFieldAdmin	0.2.2
Subversion	1.8.0 (r1490375)
RPC	1.0.6

Python Traceback

Traceback (most recent call last):
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.7-py2.5.egg/trac/web/main.py", line 450, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.7-py2.5.egg/trac/web/main.py", line 229, in dispatch
    req.session.save()
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.7-py2.5.egg/trac/web/session.py", line 129, in save
    (self.last_visit, self.sid, authenticated))
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.7-py2.5.egg/trac/db/util.py", line 64, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.7-py2.5.egg/trac/db/sqlite_backend.py", line 80, in execute
    result = PyFormatCursor.execute(self, *args)
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.7-py2.5.egg/trac/db/sqlite_backend.py", line 59, in execute
    args or [])
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11.7-py2.5.egg/trac/db/sqlite_backend.py", line 51, in _rollback_on_error
    return function(self, *args, **kwargs)
OperationalError: database or disk is full

[Jun Omae]

MaintenanceIssue.

[Ryan J Ollos]

Searching for OperationalError: database or disk is full reveals 14 tickets on t.e.o. I was looking into whether it might be worthwhile to present a TracError to the user, rather than presenting the traceback.

It looks like we could raise a TracError​ for the case when [trac] debug_sql = enabled, but I'm guessing that the self.cursor.execute/self.cursor.executemany calls aren't wrapped in a try/except when [trac] debug_sql = disabled because performance would be degraded.