On Mon, Jul 21, 2008 at 12:17:14PM +0100, Ian G Batten wrote:
>
> On 19 Jul 08, at 1313, Bron Gondwana wrote:
>>
>> Unfortunately, the cyrus database interface sort of sucks from
>> a consistency perspective, it's dangerous to call any function
>> that needs database access if you have a database transaction
>> open
>
> I understand some of the technical, philosophical and historical reasons
> why this isn't the case, but every now and again I find myself wishing
> that Cyrus had an SQL backend for the various databases (perhaps not
> delivery, because losing it isn't the end of the world, but certainly for
> mailboxes).
>
> In our case, we have really big Oracle and Postgres systems that could
> proably handle the load imposed by out mailsystem metadata as well as
> our mailsystem copes with it itself via skiplist, but we would could
> then manage those databases with the same tools we use for the
> production systems (hot backups, replication, etc).
>
> Losing the mailboxes database can spoil your whole day, and the lengths
> we go to to keep it safe (snapshots of the filesystem, hourly runs of
> ctl_mboxlist -d, etc, etc should really be necessary if it were in a
> production SQL database.
>
> In my copious spare time, I might take a pass at the cope and see how
> hard it looks.
Muahahahahaha.
Erhum.
Actually, the interface itself isn't that bad.
Managing transactions might give you headaches though.
And connections would probably be per-imapd process, so be prepared to
have 4k connections sitting mostly idle or lots of startup/shutdown of
connections.
Bron ( not having done any real C library SQL coding myself, I'd suggest
probably some sort of generic DBI-style layer than a single
database at a time if you go this route )
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
