Re: [Dbmail-dev] Can't run dbmail revision 1940
Add: TRACE_SYSLOG=1 TRACE_STDERR=0 to your dbmail.conf as documented in the example config. This one had me stumped as well last week :-( Oleg Lapshin wrote: Hello. I compiled dbmail rev 1940. Run dbmail-imapd and no messages at all.(TRACE_LEVEL=5) no forking, no work. I attach output from strace dbmail-imapd -n -v command (only dbmail-imapd -V and dbmail-imapd -h give me output) -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlandshttp://www.nfg.nl
Re: [Dbmail-dev] Can't run dbmail revision 1940
On Fri, 2005-12-16 at 14:05 +0300, Oleg Lapshin wrote: В сообщении от 16 декабря 2005 13:44 Paul J Stevens написал(a): Add: TRACE_SYSLOG=1 TRACE_STDERR=0 to your dbmail.conf as documented in the example config. This one had me stumped as well last week :-( Sorry ;) Output: Dec 16 13:48:23 bagira dbmail/imap4d[3862]: dbmysql.c,db_connect: mysql_real_connect failed: Unknown MySQL server host 'localhost # host for database, set to localhost if database is om ' (3) I had in config: host=localhost # host for database, set to localhost if database is om # the same host as dbmail and you want to use a local socket # for connecting. and when I change to: host=localhost # host for database, set to localhost if database is om # the same host as dbmail and you want to use a local socket # for connecting. (add newline after localhost) dbmail-imapd is runing So, are there errors in parsing config file? or comments _must_ begin with newline? The problem was that you didn't have the two config items TRACE_SYSLOG and TRACE_STDERR. I thoughlessly made those mandatory with a stupid fatal error message. Aaron
Re: [Dbmail-dev] Can't run dbmail revision 1940
The problem was that you didn't have the two config items TRACE_SYSLOG and TRACE_STDERR. I thoughlessly made those mandatory with a stupid fatal error message. NO! When I try to run dbmail-imapd with this in config: TRACE_LEVEL=5 TRACE_SYSLOG=1 TRACE_STDERR=0 host=localhost # host for database, set to localhost if database is om dbmail-imapd don't run! but when I change to host=localhost # host for database, set to localhost if database is om (newline after localhost) dbmail-imapd run. -- Oleg Lapshin
Re: [Dbmail-dev] STORE is SLOOOOOW on folder with many, many messages
On Thu, 2005-12-15 at 14:24 -0800, Kevin Brown wrote: Geo Carncross wrote: I know we talked about this earlier, but I think for 2.2 we need to make it possible to have multiple queries- we talked about it per database layer, but why not a global conformance level setting? DB_CAN_VIEW DB_CAN_TRIGGER DB_CAN_SUBSELECT DB_CAN_FOREIGNKEY (etc) and select the appropriate query at that point? Hmm...if you're going to do that, perhaps it would be better to just put the queries and the immediate logic that goes around them into the db-specific code files. Then it's a matter of making the proper function calls from the db-independent code. That's what had been originally proposed, but there are a number of problems with it: * It has to be done all at once, or someone will complain it looks ugly * It's harder to test all backends equally * It would be a lot of work * Nobody wanted to do it :) With this idea, it can be implemented incrementally, which is good, because there are (presently?) only a few queries like this. Any DB could then step down their conformance setting to check out the performance of the other queries with their database. Might be more work keeping things synchronized as development proceeds, but you'd be able to use all the capabilities of whatever backend you're talking to without fear. In fact, if you did this right, you could make the backend representation at the table level completely different between databases if that proved to be advantageous. I like that last part, but I'm hoping for something to keep 2.2 compatible with 2.0... -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] STORE is SLOOOOOW on folder with many, many messages
On Thu, 2005-12-15 at 14:16 -0800, Kevin Brown wrote: Paul J Stevens wrote: And I suspect 5.0 will be become a requirement for 2.3+ so we can start working with views, triggers, etc... Hmm...that would imply ditching SQLite, wouldn't it? Not that I have a problem with that, mind you. Why? SQLite has subselects, transactions, views and triggers. It's also faster in most of the dbmail tests (largely: bulk inserts and long search statements) that I ran than Pg 7, Pg 8, and SQLite. It uses an optimal algorithm for COUNT(*), and can avoid touching the database when the indexes can supply all the data for a SELECT. It also has a query-plan generator/debugger- albeit not quite as nice as Pg. Historically, I've found it faster than Pg7 and MySQL 3 and 4 in most of my own applications, and I've even used it in a distributed database application. If I'm missing something... -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] Can't run dbmail revision 1940
There're not fatal. But when they are missing there's no logging at all! Which effectively hides the cause of any fatal errors :-) Aaron Stone wrote: That's dumb, why are those TRACE_FATAL when not found? I just copied it twice more to the new options; I don't think any failure to find the TRACE_* config options should be FATAL, just result in sane defaults. I'll make it part of my trace-fixing project to fix that! Aaron On Fri, 2005-12-16 at 11:44 +0100, Paul J Stevens wrote: Add: TRACE_SYSLOG=1 TRACE_STDERR=0 to your dbmail.conf as documented in the example config. This one had me stumped as well last week :-( Oleg Lapshin wrote: Hello. I compiled dbmail rev 1940. Run dbmail-imapd and no messages at all.(TRACE_LEVEL=5) no forking, no work. I attach output from strace dbmail-imapd -n -v command (only dbmail-imapd -V and dbmail-imapd -h give me output) ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlandshttp://www.nfg.nl
Re: [Dbmail-dev] STORE is SLOOOOOW on folder with many, many messages
Geo Carncross wrote: On Thu, 2005-12-15 at 14:16 -0800, Kevin Brown wrote: Paul J Stevens wrote: And I suspect 5.0 will be become a requirement for 2.3+ so we can start working with views, triggers, etc... Hmm...that would imply ditching SQLite, wouldn't it? Not that I have a problem with that, mind you. Why? SQLite has subselects, transactions, views and triggers. Oh. Wow. I'm surprised and impressed. It has stored procs as well? I have no real experience with SQLite... Historically, I've found it faster than Pg7 and MySQL 3 and 4 in most of my own applications, and I've even used it in a distributed database application. I wonder how well it handles lots of concurrency... -- Kevin Brown [EMAIL PROTECTED]
Re: [Dbmail-dev] FIX FOR SQLITE - was STORE is slow or something...
On Fri, 2005-12-16 at 11:11 -0800, Kevin Brown wrote:
Geo Carncross wrote:
On Thu, 2005-12-15 at 14:16 -0800, Kevin Brown wrote:
Paul J Stevens wrote:
And I suspect 5.0 will be become a requirement for 2.3+ so we can
start working with views, triggers, etc...
Hmm...that would imply ditching SQLite, wouldn't it?
Not that I have a problem with that, mind you.
Why? SQLite has subselects, transactions, views and triggers.
Oh. Wow. I'm surprised and impressed.
It has stored procs as well? I have no real experience with SQLite...
Not exactly. You can use triggers, but it's single process and that
process is always local: You can make custom functions and aggregates,
either in C, perl, TCL (possibly others) - which albeit, isn't the same
thing, but it's good enough for most cases.
Look at sqlite/dbsqlite.c - note the dbsqlite_current_timestamp()
function for an example of a custom function (CURRENT_TIMESTAMP)
Although, now that I'm looking at it, what's this SQL_REPLYCACHE_EXPIRE
thingy? That's just wrong.
The correct statement is:
const char *SQL_REPLYCACHE_EXPIRE = (CURRENT_TIMESTAMP_UNIX()-%s);
Then a:
static void dbsqlite_current_timestamp_unix(sqlite_func *f, int argc
UNUSED, const char **argv UNUSED)
{
char buf[63];
sprintf(buf, %ld, time(NULL)); /* assumes time() is signed int */
(void)sqlite_set_result_string(f,buf,-1);
}
And in db_connect,
if (sqlite_create_function(conn, CURRENT_TIMESTAMP_UNIX, 0,
dbsqlite_current_timestamp_unix, 0) != SQLITE_OK) {
sqlite_close(conn);
trace(TRACE_ERROR,
%si,%s: sqlite_create_function failed, __FILE,__func__);
return -1;
}
(right before the return 0);
Historically, I've found it faster than Pg7 and MySQL 3 and 4 in most of
my own applications, and I've even used it in a distributed database
application.
I wonder how well it handles lots of concurrency...
Read concurrency? Just fine.
Write concurrency? Very poorly :)
There are things you can do to speed it up (the ATTACH syntax is a good
one)- but see for dbmail, I have one SQLite database per mailbox because
I'm not interested in sharing them -- If I were, I would use the ATTACH
syntax to join two database files into one database (for the session).
Since writing a message to the database doesn't take long, and the IMAP
user wouldn't notice anyway (in Pg because of row-versioning) it's not
so bad, really.
In fact: for most tasks, I've found SQLite is just fine. CVSTrac (for
example) is a web-based wiki + CVS-oriented bugtracker that uses SQLite,
and it handles plenty of traffic :)
... but then, writes are less frequent than reads, and in general very
very fast.
About the only time SQLite performs poorly is when writes take a long
time AND are monopolizing the time. In those cases, Pg is usually what I
use (because of versioning) -as usually in these cases, MySQL would
never perform any better (usually much worse with global table locking)
- anyway, I haven't used MySQL for a while :)
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
