Re: Sqlite akonadi transaction mode fix
Am Mittwoch, 21. Januar 2015, 09:49:18 schrieb David Goodenough:
> I use KdePIM and thus akonadi with SqLite. I am running unstable and am
> up to date with fixes.
No. Its no default. Default is Akonadi with MySQL. If you use SQLite, AFAIK
you chose that yourself explicetely. So its no "thus" here, cause you have a
choice which backend to use.
> 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?
I read again and again, that KDEPIM developers themselves recommend not to use
SQLite backend. I used PostgreSQL backend for some time, but now use MySQL
backend as I believe it is most widely tested. But AFAIK as least one KDEPIM
developers uses the PostgreSQL backend. It has the disadvantage tough that on
major PostgreSQL updates you have to dump and restore the database to upgrade
its structures.
I compiled akonadi and kdepim myself quite some time, but not from package,
but installed it to /usr/local and initialized it with some environment
variable settings. Its all described on kde wiki sites.
As to using Debian packages: Well basically its grab the source, change,
rebuild. You would need quite some build dependencies satisfied, but you need
that either way. The turn around time would be higher than just compiling and
installing with make install I think, but I bet you wouldn´t need to do this
often.
That said, I didn´t rebuild KDEPIM related packages yet, but I did this with
Digikam and it worked quite nice.
As for updates to Debian packages, I´d like to see current akonadi 1.13 branch
packages, cause it contains quite some noticeable performance updates
regarding database access that made MySQL disappear from cpu usage top for
most of the time. Its really a huge difference.
I use c733429f4fa9696fb027ddc946e54f6bbb68deaf of Akonadi git repo on two of
my systems for at least a month and it works nice.
And well if what you point to is really a fix, I bet it may be cherry-picked
for the package. But if you can verify first, that the fix works, I think
chances are higher to convince a Debian Qt/KDE team member to merge the
change. So your idea of testing it locally by compiling yourself makes sense
to me.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: