Morning all,
does anyone know if Postgres (10) can be used again as akonadi-backend?
Background: After updating from Leap 42.3 to 15, the whole akonadi backend seems to be rebuild. I remember some time back the same issue on a TW machine, caused by some technical changes in akonadi.
This rebuild is using all CPU and seems to need forever ( >10h) , so I tried already to stop akonadi and delete ~/.local/share/baloo/ and ~/.local/share/akonadi/search_db/, by this forcing a reindex. This is currently running…
So, in case I have to flush the local akonadi storage, it might be worth to give the postgres backend a try, as this was reported to run much smoother than mySQL.
Never tried it myself though, I’m fine with the mysql backend.
Btw, if the akonadi database has to be upgraded, deleting ~/.local/share/baloo/ and ~/.local/share/akonadi/search_db won’t have any effect, these contain just the search index and are not really related to Akonadi itself. Actually, during the database migration/upgrade, nothing Akonadi related should be running yet, actually, because this is done before any other Akonadi processes are started.
I know regarding the relevance of deletion of the above directories and the change of DB backend. Anyway, search DB corruption seems to be a frequent thing anyway - just started akonadi on my TW system:
docb@T520:~> akonadictl start
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
docb@T520:~> akonadi.collectionattributetable OK
akonadi.collectionmimetyperelation OK
akonadi.collectionpimitemrelation OK
akonadi.collectiontable OK
akonadi.flagtable OK
akonadi.mimetypetable OK
akonadi.parttable OK
akonadi.parttypetable OK
akonadi.pimitemflagrelation OK
akonadi.pimitemtable OK
akonadi.pimitemtagrelation OK
akonadi.relationtable OK
akonadi.relationtypetable OK
akonadi.resourcetable OK
akonadi.schemaversiontable OK
akonadi.tagattributetable OK
akonadi.tagremoteidresourcerelationtable OK
akonadi.tagtable OK
akonadi.tagtypetable OK
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadi_indexer_agent: Database Corrupted - What did you do?
org.kde.pim.akonadi_indexer_agent:
org.kde.pim.akonadi_indexer_agent: Failed to fetch items: "Collection does not exist"
org.kde.pim.akonadi_indexer_agent: Indexing failed: ""
true
Looks like a deletion of search DB is required as well…
Seems so.
But that’s unrelated to the database migration/upgrade that you talked about in the first post. At that point, the search database is not being accessed at all yet.
Right
to complete the OT: akonadictl fsck throws (beside others)
Checking Papierkorb
Found duplicates 3396
org.kde.pim.akonadiserver: DATABASE ERROR:
org.kde.pim.akonadiserver: Error code: "1064"
org.kde.pim.akonadiserver: DB error: "You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ') AND PartTable.storage = 1 )' at line 1"
org.kde.pim.akonadiserver: Error text: "You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ') AND PartTable.storage = 1 )' at line 1 QMYSQL: Die Abfrage konnte nicht ausgeführt werden"
org.kde.pim.akonadiserver: Query: "SELECT PartTable.id, PartTable.pimItemId, PartTable.partTypeId, PartTable.data, PartTable.datasize, PartTable.version, PartTable.storage FROM PartTable WHERE ( PartTable.pimItemId IN ( ) AND PartTable.storage = :0 )"
Checking Sent
PS, as you asked about changing the akonadi backend in the first place: this is not used for storing the search database, only Akonadi’s own tables.
akonadi-search uses Xapian, and only that.
So changing the Akonadi Backend will likely not help with your apparent search db corruption problems.
Sure, there seems to be a problem with the SQL query that is being used.
Probably some wrong parameter substitution or some missing check, the list is empty in “PartTable.pimItemId IN ( )”.
And “PartTable.storage = :0” doesn’t look correct to me either…
