On 04/14/2014 05:56 AM, Laurent Rineau wrote:
Le Monday 14 April 2014 10:13:20 José Matos a écrit :
> On Thursday 10 April 2014 23:29:57 José Matos wrote:
>> Hi Daniel,
>> the akonadi server seems to be trapped in a continuous loop. If I
>> kill one another one is started. So it is not obvious how to proceed.
>> Looking to top I notice that there is a mysqld process running for 55
>> min (the computer is now up for 7h24m).
>> This seems to be the same pattern of yesterday.
> Just a followup, in case anyone has the same problem.
> I have solved this last Thursday with Daniel's help.
> The culprit was:
> Sql error: The total number of locks exceeds the lock table size QMYSQL:
> Unable to execute query
> Query: ALTER TABLE PartTable ADD FOREIGN KEY (pimItemId) REFERENCES
> PimItemTable(id) ON UPDATE CASCADES ON DELETE CASCADE
> and the solution was, since I am using an internal mysql server, was to
> increase the value of the innodb_buffer_pool_size parameter on
> The value that was there was of 8M and I have set it to 128M.
I was impacted by that bug too, but I did not found the correct fix. I removed
my Akonadi database last Friday.
I think that should be reported to upstream KDE, so that they find a way to
smooth the upgrade.
As a downstream/packaging issue, fedoras akonadi packaging currently
opts to default to using the values in:
(ie, compare each to /etc/aknoadi/mysql-global.conf)
The rationale being that the -big config, well, was *too* big,
especially for casual users. Perhaps we will have to rethink that.
In the meantime, yes, if the values in -mobile are problematic, then
upstream should also consider adjusting things too.