Bug 342866 - Unable to set seen flag on huge IMAP folders with many unread messages
Summary: Unable to set seen flag on huge IMAP folders with many unread messages
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: IMAP resource (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Christian Mollekopf
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-15 09:42 UTC by Hans-Peter Jansen
Modified: 2018-02-01 09:55 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
bigger mysql.conf (3.31 KB, text/plain)
2015-01-15 17:37 UTC, Hans-Peter Jansen
Details
big mysql.conf (3.31 KB, text/plain)
2015-01-15 17:37 UTC, Hans-Peter Jansen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans-Peter Jansen 2015-01-15 09:42:41 UTC
Bugzilla doesn't know about the current akonadi version: 4.14.3 in my case (openSUSE 13.2/x86_64)

When trying to set many unread messages to "SEEN", akonadi throws an error in the terminal, I've manually started it (akonadictl start). IMAP server is a Cyrus 2.3.11 (also an older openSUSE release):

DATABASE ERROR:
Error code: 1064
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 ':0 AND PimItem_id IN ( :1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :' at line 1"
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 ':0 AND PimItem_id IN ( :1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :' at line 1 QMYSQL: Unable to execute query"
Query: "SELECT PimItem_id FROM PimItemFlagRelation WHERE ( ( Flag_id = :0 AND PimItem_id IN ( :1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19, :20, :21, :22, :23, :24, :25, :26, :27, :28, :29, :30, :31, :32, :33, :34, :35, :36, :37, :38, :39, :40, :41, :42, :43, :44, :45, :46, :47, :48, :49, :50, :51, :52, :53, :54, :55, :56, :57, :58, :59, :60, :61, :62, :63, :64, :65, :66, :67, :68, :69, :70, :71, :72, :73, :74, :75, :76, :77, :78, :79, :80, :81, :82, :83, :84, :85, :86, :87, :88, :89, :90, :91, :92, :93, :94, :95, :96, :97, :98, :99, :100, :101, :102, :103, :104, :105, :106, :107, :108, :109, :110, :111, :112, :113, :114, :115, :116, :117, :118, :119, :120, :121, :122, 
[...]
 :130749, :130750, :130751, :130752, :130753, :130754, :130755, :130756, :130757, :130758, :130759, :130760, :130761, :130762, :130763, :130764, :130765, :130766, :130767, :130768, :130769, :130770, :130771, :130772, :130773, :130774 ) ) )
"
Failed to execute query: QSqlError(1064, "QMYSQL: Unable to execute query", "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 ':0 AND PimItem_id IN ( :1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :' at line 1") 
Store::addFlags: Unable to add new item flags 

Yes, we're talking about 128k mails here. Smaller operations work fine, of course.
It smells like some buffer overflow in sql command processing, but I tried to raise the buffer limits in .local/share/akonadi/mysql.conf already with no better result.

Any idea, what's going wrong here.
Comment 1 Hans-Peter Jansen 2015-01-15 17:37:33 UTC
Created attachment 90431 [details]
bigger mysql.conf
Comment 2 Hans-Peter Jansen 2015-01-15 17:37:59 UTC
Created attachment 90432 [details]
big mysql.conf
Comment 3 Hans-Peter Jansen 2015-01-15 17:41:06 UTC
Besides default, I tried those mysql settings. openSUSE comes with mariadb 10.0.13, that doesn't allow for logging queries as documented, neither slow nor all, BTW.
Comment 4 Denis Kurz 2017-06-23 20:04:07 UTC
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it.

Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Comment 5 Denis Kurz 2018-02-01 09:55:31 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12; preferably much more recent), please open a new one unless it already exists. Thank you for all your input.