> And, to tell developers that we probably need a log file of our own. I'm > unable to implement it as I am not familiar enough with the C library, > and with the code (to understand where the file should be opened and > closed), and with working with files from forked processes. > > This is a MAJOR speed issue. I think it's a blocker for 2.0.1.
Agreed, it should be fixed. But if it is introduced to 2.0.1 then it should be an OPTION, not default behaviour. Don't break backwards compatibility in a stable series. But my suggestion would be to log directly to database, that would solve all locking issues and performance should not be hurt. It might even be viable to have a buffering option that only writes out to the database every 10'th message or so. This could be done in a transaction to avoid locking the database too often aswell. I would appreciate the following options: -Log to database or syslog -Option to buffer logging to database (and syslog?) This enables us to take advantage of transactions support aswell. -Possibility to specify some other host and database for logging This is very good for heavily loaded mail systems. -Max log age parameter (cleanup util does the deletions at night) -Max log size in records/size (cleanup util does the deletions at night) -HK
