Re: Sqlite akonadi transaction mode fix
On Wednesday 21 January 2015 09:49:18 David Goodenough wrote:
> I use KdePIM and thus akonadi with SqLite. I am running unstable and am
> up to date with fixes.
>
> Looking in the KDE bug database I found:-
>
> http://osdir.com/ml/kde-commits/2014-07/msg02228.html
>
> which seems to address the repeated dialog boxes I get while filters run on
> my mailboxes, and the log messages of which:-
>
> DATABASE ERROR:
> Error code: 6
> DB error: "database is deadlocked"
> Error text: "database is deadlocked Unable to fetch row"
> Query: "UPDATE PimItemTable SET atime = ? WHERE ( ( PimItemTable.id = ? )
> )"
>
> is an example. All the errors I get currently are deadlock errors.
>
> I don't think this fix is in the current build, and I realise that Debian is
> getting ready for a new release and thus it is unlikely that this fix will
> be able to be slotted in any time soon. Can I simply get the source, add
> this one patch and rebuild, or is it more complicated. Also which
> package(s) would I have to rebuild? Is it just akonadi-backend-sqlite?
>
> David
Well having loaded the source and looked at it, this patch is already in
the system.
What this says is that some of the database statements are being executed
not in an explicit transaction. If you use transactions it is required that
ALL statements are done this way, otherwise the DB will add put default
transactions around the unbounded statements and they will not be
in the right mode (in this case IMMEDIATE). Normally this will not be a
problem, and quite possibly other DBs will get away with this, but SqLite
has a non-standard way of doing the locking (this IMMEDIATE mode in the
BEGIN TRANSACTION) and my guess is that this is the root of the problem.
When I have time I will look at the specific SQL statements that are failing
and see if that finds some of the missing beginTransaction calls.
David
Reply to: