Shane Kerr wrote: > All, > > On Wed, 2008-08-20 at 16:52 +0200, Shane Kerr wrote: >> I assume this is because SQLite does table-level locking, and multiple >> messages are arriving at one time. Maybe this has something to do with >> the truncation? I have moved to PostgreSQL, and will see if the problem >> seems to go away. >> >> If this is the case, I think I'll put a big scary warning on the wiki >> site saying, "DO NOT USE SQLite FOR ANYTHING OTHER THAN TESTING >> PURPOSES". Or is that already there and I missed it? :)
People *are* using it in production. And I do run full round-trip unit-testing before releasing dbmail. Those should catch these kinds of problems. > > I turned off the SQLite version at 16:22 yesterday, and turned up the > PostgreSQL version shortly afterwords. > > Mails that arrived at 15:29, 15:41, and 15:57 were all truncated at the > end. > > Mails that arrived since then, at 16:46, 16:53, 16:57, 16:59, 19:58, > 22:18, 23:15, 00:04, 06:59, and 10:01 have no truncation. > > I am not 100% sure, but I think the problem is fixed. > > > > So, that is fine for me. But what about other users, and the state of > SQLite in dbmail in general? > > Does anyone use SQLite in production? If not, I will update the Wiki > with a warning if nobody objects. Please post a bugreport instead. > > It is possible that using lmtp makes the problem much less severe, or > even eliminates it, since you have a lot less chances for concurrent > access to the database file. (It will still be possible sometimes, > because dbmail-imapd also needs to modify the database.) > > It is possible that dbmail 2.3 does not have this problem, because of > the Zild database library may have slightly different semantics. I havent seen this problem but I'll double check... > > Finally, it is also possible to use Unix file-locking operations to lock > the database file on open (meaning lockf() or something like that), > rather than relying on SQLite to do this. I went ahead and coded this > up, although I haven't tested it. It's a bit of a hack, but I think it > should work. See the patch at the end. Why on earth won't you simple rely on sqlite to do it's own locking?? -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
