Akonadi is not just a cache (was: Re: Postgres problem)

No cc needed for me.

Michael Hirsch - 29.10.23, 01:58:46 CET:
> ive it a try...you need postgres 9 and 16 installed.
> 
> > For a 'brand new' install, its more akdepim  guess than a proposal:
> > Backup everything, delete $HOME/.local/share/akonadi/db_data and see
> > if it sets up a new DB from the config in $HOME/.config/akonadi Not
> > sure if it works
> 
> I did this with my MySQL backed kdepim and it worked well.  But it
> wasn't postgres.

This will work. However Akonadi is unfortunately not just a cache.

I have written this here countless times but I do not find the blog post 
again that explains it that I referenced at the moment.

Anyway, it can happen that a mail temporarily is *only* in the database. 
There is the database and there is remote storage. For mails remote 
storage can be an IMAP server or local maildir, it means it is remote from 
the viewpoint of the database. Database is MariaDB by standard, optionally 
PostgreSQL or SQLite *plus* "file_db_data" directory for larger payloads, 
for example bigger mails. There is a certain threshold for that.

Even with local maildir storage it somehow can happen that Akonadi is not 
able to store the mail in maildir on the first attempt.  This leads to 
messages like

Item "3196866" in collection "251" has no RID.

in "akonadictl fsck" output. RID is remote identifier. It may be happen on 
stopping Akonadi manually or on a forced reboot.

And it does not try again. Which to me is a clear data loss bug that has 
still not been resolved as far as I am aware.

Thus when removing the database, it *may* be that you loose content that 
is not stored elsewhere.

However… I actually changed database several times and got away with it. I 
did not find anything missing. Maybe with local maildir some of the 
triggers for item without RID is stopping Akonadi manually or forcibly 
shutting down the laptop. And maybe is some circumstances the mail is 
being tried to be stored again. At least in practice I never found 
anything missing. However, how do I even know with about 1,5 millions of 
mails stored locally? Thus I usually aim to keep the database and only 
change when deciding for a different type of database. Like at one point I 
may switch from PostgreSQL to SQLite to get rid of the regular PostgreSQL 
updates. In the end I am just using a mail program. Why would I need to be 
a database admin for that?

It may be good practice to keep the old database including file_db_data for 
a while after starting from scratch, so that you at least have a chance to 
somehow recover in case you find anything missing. But then you need to dig
into database structure in order to find the mail that is missing.

Ciao,
-- 
Martin