Postgres as Akonadi-Backend

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.

Sure, why not.

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: Failed to fetch items:  "Collection does not exist"
org.kde.pim.akonadi_indexer_agent: Indexing failed:  ""

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 :slight_smile:
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 = 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 = 1 )' at line 1 QMYSQL: Die Abfrage konnte nicht ausgeführt werden"
org.kde.pim.akonadiserver:   Query: "SELECT, PartTable.pimItemId, PartTable.partTypeId,, PartTable.datasize, PartTable.version, FROM PartTable WHERE ( PartTable.pimItemId IN (  ) AND = :0 )"
Checking Sent

Worth filing a bug on

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.

Just thought I’d mention it.

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 “ = :0” doesn’t look correct to me either… :wink:

This is latest TW (i.e. 18.04.1), right?