akonadi migration to postgres12 was OK, but akonadi does not start

English Applications
1

Morning,
Akonadi migration to postgres 12 worked obviously well:

xel@southpole:~> cp -R $HOME/.local/share/akonadi/db_data $HOME/.local/share/akonadi/db_data_9
axel@southpole:~> mv $HOME/.local/share/akonadi/db_data $HOME/.local/share/akonadi/db_data_old
axel@southpole:~> /usr/lib/postgresql12/bin/initdb --pgdata=$HOME/.local/share/akonadi/db_data --locale=en_US.UTF-8 
Die Dateien, die zu diesem Datenbanksystem gehören, werden dem Benutzer
»axel« gehören. Diesem Benutzer muss auch der Serverprozess gehören.

Der Datenbankcluster wird mit der Locale »en_US.UTF-8« initialisiert werden.
Die Standarddatenbankkodierung wurde entsprechend auf »UTF8« gesetzt.
Die Standardtextsuchekonfiguration wird auf »english« gesetzt.

Datenseitenprüfsummen sind ausgeschaltet.

erzeuge Verzeichnis /home/axel/.local/share/akonadi/db_data ... ok
erzeuge Unterverzeichnisse ... ok
wähle Implementierung von dynamischem Shared Memory ... posix
wähle Vorgabewert für max_connections ... 100
wähle Vorgabewert für shared_buffers ... 128MB
wähle Vorgabewert für Zeitzone ... Europe/Berlin
erzeuge Konfigurationsdateien ... ok
führe Bootstrap-Skript aus ... ok
führe Post-Bootstrap-Initialisierung durch ... ok
synchronisiere Daten auf Festplatte ... ok

initdb: Warnung: Authentifizierung für lokale Verbindungen auf »trust« gesetzt
Sie können dies ändern, indem Sie pg_hba.conf bearbeiten oder beim
nächsten Aufruf von initdb die Option -A, oder --auth-local und
--auth-host, verwenden.

Erfolg. Sie können den Datenbankserver jetzt mit

    /usr/lib/postgresql12/bin/pg_ctl -D /home/axel/.local/share/akonadi/db_data -l logdatei start

starten.

xel@southpole:~> /usr/lib/postgresql12/bin/pg_upgrade -b /usr/lib/postgresql96/bin -B /usr/lib/postgresql12/bin -d $HOME/.local/share/akonadi/db_data_old -D $HOME/.local/share/akonadi/db_data 
Führe Konsistenzprüfungen durch
-------------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               ok
Checking for invalid "sql_identifier" user columns          ok
Checking for invalid "unknown" user columns                 ok
Creating dump of global objects                             ok
Creating dump of database schemas
                                                            ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok

Wenn pg_upgrade ab diesem Punkt fehlschlägt, dann müssen Sie den
neuen Cluster neu mit initdb initialisieren, bevor fortgesetzt
werden kann.

Führe Upgrade durch
-------------------
Analyzing all rows in the new cluster                       ok
Freezing all rows in the new cluster                        ok
Deleting files from new pg_xact                             ok
Copying old pg_clog to new server                           ok
Setting next transaction ID and epoch for new cluster       ok
Deleting files from new pg_multixact/offsets                ok
Copying old pg_multixact/offsets to new server              ok
Deleting files from new pg_multixact/members                ok
Copying old pg_multixact/members to new server              ok
Setting next multixact ID and offset for new cluster        ok
Resetting WAL archives                                      ok
Setting frozenxid and minmxid counters in new cluster       ok
Restoring global objects in the new cluster                 ok
Restoring database schemas in the new cluster
                                                            ok
Kopiere Benutzertabellendateien
                                                            ok 
Setting next OID for new cluster                            ok
Sync data directory to disk                                 ok
Creating script to analyze new cluster                      ok
Creating script to delete old cluster                       ok
Checking for hash indexes                                   ok

Upgrade abgeschlossen
---------------------
Optimizer-Statistiken werden von pg_upgrade nicht übertragen. Wenn Sie
den neuen Server starten, sollte Sie diesen Befehl ausführen:
    ./analyze_new_cluster.sh

Mit diesem Skript können die Dateien des alten Clusters gelöscht werden:
    ./delete_old_cluster.sh

So, everything looks good, but:

axel@southpole:~> akonadictl start
org.kde.pim.akonadictl: Starting Akonadi Server...
org.kde.pim.akonadictl:    done.
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadiserver: Starting up the Akonadi Server...
(QFileInfo(/usr/lib/postgresql/bin), QFileInfo(/usr/lib/postgresql/lib64))
org.kde.pim.akonadiserver: Running DB initializer
org.kde.pim.akonadiserver: "
Sql error: ERROR:  column \"version\" of relation \"schemaversiontable\" already exists
(42701) QPSQL: Unable to create query
Query: ALTER TABLE SchemaVersionTable ADD COLUMN version INTEGER NOT NULL DEFAULT 0"
org.kde.pim.akonadiserver: Unable to initialize database.
warte auf Herunterfahren des Servers.... fertig
Server angehalten
org.kde.pim.akonadiserver: Shutting down AkonadiServer...
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally...

Any idea?

2

Hello,

I will not say that it is impossible that some of the members here will have useful comments on this, but my idea is that you might have a better audience at the KDE PIM mailing list: kdepim-users@kde.org
I have seen there many discussions about changing from MySQL to Postgres and also Akonadi problems in general.

3

Maybe I should have added this:
https://mail.kde.org/mailman/listinfo/kde-pim

4

Hello Henk,
yes, the KDE mailing list may be the better place. I have filed a bug in between: https://bugs.kde.org/show_bug.cgi?id=423918 (and returned to postgres96 for the time being)

5

Hello, sorry if this might look like thread highjack, but is postgres a better db manager than mysql ?
Many people on the kdepim mayling list complain about mysql. Why did suse choose mysql then ?
If postgres is a better db manager, can you describe the best way to move from mysql to postgres without the error you described ? (now my post doesn’t look anymore like a thread highjack ;o)
Thanks

6

It is always better to create a new thread when your problem is not 100% exactly the same (and it isn’t).

Why?

  • A new thread with a new thread title (you would not use the same title as above wouldn’t you, because you ask something differnt) will draw the attention of people that think they can help for this case and thus they might open the thread. Most people will not see that you have added a new question at the end of an existing thread where they have no interest in. So it is in your interest to advertise your question/problem by showing it in the list of new threads.
  • Having different problems/questions in the same thread will lead to confusing discussions. Some people will avoid such threads by default.

And my idea about your question.

I will not say that it is impossible that some of the members here will have useful comments on this, but my idea is that you might have a better audience at the KDE PIM mailing list: kdepim-users@kde.org
I have seen there many discussions about changing from MySQL to Postgres and also Akonadi problems in general.

You may have read this earlier.

7

My bad. Sorry : Here’s the fork : https://forums.opensuse.org/showthread.php/540977-Kmail-Migration-which-db-manager-Mysql-Postgres-Else?p=2942051#post2942051

8

That is fine.

To others, please, for @Christophe_deR’s question go to his new thread and not here.