Bug 267807 - Message status cannot be changed to "read" with postgresql backend
Summary: Message status cannot be changed to "read" with postgresql backend
Status: RESOLVED DUPLICATE of bug 265155
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: 1.5.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-06 17:53 UTC by S.Trzmiel
Modified: 2011-03-09 10:25 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
requested akonadi server config (463 bytes, text/plain)
2011-03-07 11:59 UTC, S.Trzmiel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description S.Trzmiel 2011-03-06 17:53:33 UTC
Version:           1.5.0 (using KDE 4.6.1) 
OS:                Linux

In last few days I experienced some problems with high memory usage of MySql akonadi backend (mysql crossed 100MB of used ram) so decided to give Postgresql backend a try.
I created user akonadi then database with sql query:

CREATE DATABASE akonadi
  WITH OWNER = akonadi

       TABLESPACE = pg_default
       CONNECTION LIMIT = -1;

Additional parameters were added ny postgresql as database default parameters:
       ENCODING = 'UTF8'
       LC_COLLATE = 'pl_PL.UTF-8'
       LC_CTYPE = 'pl_PL.UTF-8'

Akonadi serwer statred properly without any errors but, after db backed switch KMail couldn't change message status. All the mails has "unread" status Also empty folders shows they contain 1 unread message.
Marking messages/folders as read manually also doesn't work,.

That's example message from Akonadi konsole when I tried to manually mark the message:
------------------------------------------
kmail2-876347754 (0x9964e88) 45 OK UID FETCH completed 
kmail2-876347754 (0x9964e88) 46 UID STORE 2599 REV 2 (REMOTEID "1293633982.25466.emKPp:2,S" +FLAGS (\SEEN) ATR:MDNStateAttribute "I") 
kmail2-876347754 (0x9964e88) 46 NO Unable to create flag 
kmail2-876347754 (0x9964e88) 48 UID STORE 2599 REV 2 (REMOTEID "1293633982.25466.emKPp:2,S" +FLAGS (\SEEN)) 
kmail2-876347754 (0x9964e88) 48 NO Unable to create flag 
-------------------------------------------------------------------------------------

Flags (as activity, important, tracked/ignored) works propeerly.
Also I believe unablility to set message status causes my imap folders fail to synchronize.

------------------------------------------------------------------------
Version of related software:

Fedora 14
KDE 4.6.1

kdepim-4.5.94.1-4.fc14.i686
akonadi-1.5.0-0.1.fc14.i686
postgresql-server-8.4.7-1.fc14.i686

Reproducible: Always

Steps to Reproduce:
Create akonadi user and db in postgres.
Stop akonadi server, switch db backend, start akonadi again
Launch kmail2

Actual Results:  
Messages status cannot be changed, it's permanently set as "unread".

Expected Results:  
Maunal/automatic unread -> read status change is possible
Comment 1 Christophe Marin 2011-03-07 11:36:44 UTC
(In reply to comment #0)
> I created user akonadi then database with sql query:

why ?

The default is to let Akonadi start its own postgres daemon and create a local database.

If you use an external Postgres server, you have first to make sure it's configured correctly. (which is likely not the case here)

Please paste the akonadiserverrc file content in ~/.config/akonadi
Comment 2 S.Trzmiel 2011-03-07 11:59:34 UTC
Created attachment 57742 [details]
requested akonadi server config

Here's my akonadiserverrc. A the first try I run with stock config (StartServer=true). But in my case akonadi was able to sart in own instance just when postgres service was already running else it couldn't find the server.
So I disabled running separate instance as it didnt make much sense.
I have to dig trough postgres config to find out why it's going like that.
Comment 3 Christophe Marin 2011-03-09 10:25:40 UTC
Merging with bug 265155. Read the comment bug 265155#4 for details. (this should be done *before* creating the Akonadi DB on the external server.

*** This bug has been marked as a duplicate of bug 265155 ***