Results 1 to 7 of 7

Thread: Postgres as Akonadi-Backend

  1. #1
    Join Date
    Jun 2008
    Location
    Düsseldorf/Germany
    Posts
    248

    Default 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.

  2. #2

    Default Re: Postgres as Akonadi-Backend

    Quote Originally Posted by DocB View Post
    Morning all,
    does anyone know if Postgres (10) can be used again as akonadi-backend?
    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.

  3. #3
    Join Date
    Jun 2008
    Location
    Düsseldorf/Germany
    Posts
    248

    Default Re: Postgres as Akonadi-Backend

    Quote Originally Posted by wolfi323 View Post
    Sure, why not.
    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:
    Code:
    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....

  4. #4

    Default Re: Postgres as Akonadi-Backend

    Quote Originally Posted by DocB View Post
    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.
    Last edited by wolfi323; 30-May-2018 at 03:52.

  5. #5
    Join Date
    Jun 2008
    Location
    Düsseldorf/Germany
    Posts
    248

    Default Re: Postgres as Akonadi-Backend

    Quote Originally Posted by wolfi323 View Post
    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)
    Code:
    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
    Worth filing a bug on bugs.kde.org?

  6. #6

    Default Re: Postgres as Akonadi-Backend

    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.

  7. #7

    Default Re: Postgres as Akonadi-Backend

    Quote Originally Posted by DocB View Post
    Worth filing a bug on bugs.kde.org?
    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...

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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •