Hi,
I’ve been running aox 3.1/pg 8.4 on opensolaris Illumos 151 with good results.
Upgrading to 3.2 works, but not out of the box…
I first upgraded to pg 9.1, which didn’t work so well (nothing to do with aox),
then 9.2, which doesn’t include citext.
Building aox hit some problems, first with jam (v 2.5) and gcc (version 4.4.4
(Illumos gcc-4.4.4-il-3)):
Jamrules:
-Wno-unused-result in C++FLAGS chokes g++.
core/md5.cpp has #pragma GCC chokes g++:
core/md5.cpp: In member function ‘EString MD5::hash()’:
core/md5.cpp:152: error: #pragma GCC diagnostic not allowed inside functions
core/md5.cpp:153: error: #pragma GCC diagnostic not allowed inside functions
core/md5.cpp:157: error: #pragma GCC diagnostic not allowed inside functions
I had a complain on a trunc() not casted into uint at one point (I think in
server/server.cpp), but I can’t find anything on it...
Recovering the archiveopterix database onto 9.2 led to some error messages
about ‘public’ schema, which seemed unimportant, except for the missing citext,
which is subtlely in a contrib package of pg-92.
I then tried to update the database, which gave:
root@domu:/usr/local/archiveopteryx# aox update database
Messages that might need threading: 83181.
Looking for 4096 more messages to thread.
Threading 4096 messages.
Processed 4542 messages.
Committed transaction.
Looking for 4096 more messages to thread.
Threading 4096 messages.
aox: Transaction failed: PostgreSQL Server: insert or update on table
"messages" violates foreign key constraint "messages_thread_root_fkey" (query:
update messages...)
Given I had not done a schema upgrade, was that suppose to end up this way?
The last part was to do the schema upgrade, which worked as expected with a
notice to reparse. Then aox reparse gave:
Looking for messages with parse failures
- parsing /users/AAA/INBOX/Trash:4738 still fails: Content-Language:
Unparseable value: "en -us"
- parsing /users/AAA/INBOX/Trash:4711 still fails: Content-Language:
Unparseable value: "en - us"
- parsing /users/AAA/INBOX/Trash:4719 still fails: Content-Language:
Unparseable value: "en - us"
At that point aox was back online, and it’s now in day 3 of testing it on speed
and reliability on a ~195K / 10 gb message set. So far so good, no
crash/hang/memory bloat.
One potentially out-of-date observation: most of my email domains are using aox
3.1.4 on centos, and it hangs up/dies a few times a day (using tls/ssl login).
I used aox 3.1.4 on opensolaris for endurance testing, and yet it never hang up
or died.
Next step: migrate all email domains from centos to opensolaris!
Regards,
Hugo
