Problems with the last update to akonadi [Solved]

[Rex Dieter]

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
>> ~/.local/share/akonadi/mysql.conf
>>
>> 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:
/etc/akonadi/mysql-global-mobile.conf
and not
/etc/akonadi/mysql-global-big.conf
(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.


-- Rex