I've updated the sqlite driver.
thanks.
Jens Wagner wrote:
> Hi,
>
> we are testing the use of dbmail+sqlite for mail storage in a clustered
> environment.
> When there are concurrent writes e.g. on the same dbmail-imapd mailbox,
> then most processes die because sqlite returns a SQLITE_BUSY err
Hi Jeroen,
its difficult to answer, because we have just setup the system on
heXoNet's internal infrastructure which is a quiet complex
shared-nothing cluster by itself.
Basically we follow the one mailbox <-> one database approach, with
resources (files) spread over and managed by our backe
On Fri, 2006-10-13 at 14:21 +0200, Jens Wagner wrote:
> we are testing the use of dbmail+sqlite for mail storage in a clustered
> environment.
> When there are concurrent writes e.g. on the same dbmail-imapd mailbox, then
> most processes die because sqlite returns a SQLITE_BUSY error to them. Th
Hi,
we are testing the use of dbmail+sqlite for mail storage in a clustered
environment.
When there are concurrent writes e.g. on the same dbmail-imapd mailbox, then
most processes die because sqlite returns a SQLITE_BUSY error to them. This is
a documented behaviour of sqlite.
This issue can
Steve,
Dbmail doesn't need more segments than processes running. The fact that
we're sometimes seeing this behaviour indicates a bug in dbmail.
Steve Cox wrote:
> Hello,
>
> This is teetering on "unrelated", but my /proc/sys/kernel/shmmni was set
> to 4096, and I was getting the same error. I've
Hello,
This is teetering on "unrelated", but my /proc/sys/kernel/shmmni was set
to 4096, and I was getting the same error. I've increased it to 16384.
Is this too extreme? Is it going to cause any potential issues for my
system? And how many shared segments does DBmail need? (SVN 2304/Debian
