Re: [Dbmail] Exit PostgreSQL - Make room for MySQL/InnoDB !
At 04:23 PM 2/12/2002 +0100, Roel Rozendaal - ICS wrote: * Speed.Postgresql is way slower than mysql. Way. Given that you staunchly refused to do a vacuum until the DB grew to 5GB, that's hardly surprising. Most benchmarks show that MySQL is substantially superior for one or a few clients, but that for high concurrency/high load PG wins. This of course assumes that both databases were configured and tuned properly... And for anyone who wants to start a 'MyDB is better than YourDB' discussion, please take it elsewhere. The choice is a complex one driven by a diversity of business needs; in this case mySQL may be better for ICS - they certainly seem to have more local expertise in mySQL, for example. * Dump/Restore if you create a dump using pg_dump, pg_restore will not accept it - it complains about NULL values for fields that are constrained to be 'NOT NULL'. Could be, but the fields have never been NULL in the first place as the field is constrained to be 'NOT NULL'. It is in fact very annoying to find out the dump/restore utilities do not work when trying to recover a crashed system.. You should report this as a bug; I have never seen this. As one of the people who regularly works on pg_dump/restore, I would be very interested in getting a sample dump file. * StablilityPostgresql gets _real_ bad when hardware failures occur. It cannot recover it's own stuff, claiming that it has recovered when in fact it has not. Did you report these? I have had hardware failure with PG, and only once had to revert to backups. In the worst cases the mailing lists have been extremely helpful. I think the ability to recover depends a great deal on what *was* written to disk before it died. As you suggest, it is unfair to compare without having a hardware failure on mySQL. Some very strange output from the backend follows: Did you report this? Recovering from a hardware failure may be impossible. Do you know what was trashed? * VacuumThe system turns completely irresponsive for 10-20 minutes when doing a vacuum analyze on the messageblks table - and that is on a not-so-gigantic database (ca. 5 GB). Could be done by night, but what if your mailserver has to be responsive 24/7? Not surprising if you run it for the first time when the database has grown to 5GB. You would be well advised to dump/restore the db, then run vacuum regularly. Or take it offline and run a VACUUM FULL, then vacuum regularly. Based on my own experience with DBMail, you probably need to change some other parameters to get the best performance - it depends on how much data is being updated/deleted. * Disk UsageIt seems that pgsql is eating up all disk space in time - and no vacuum full/analyze can help this. I still have to try a 'REINDEX' but - as it is marked on postgresql.org - that is intended for corrupted indices. The indices aren't corrupt, the database is just too big! Again, this is almost certainly tuning parameters. I had the same problem (growth of about 140MB per day), until I fixed some settings. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
[Dbmail] PostgreSQL tuning for dbmail
Philip Warner wrote: Most benchmarks show that MySQL is substantially superior for one or a few clients, but that for high concurrency/high load PG wins. This of course assumes that both databases were configured and tuned properly... Again, this is almost certainly tuning parameters. I had the same problem (growth of about 140MB per day), until I fixed some settings. Philip, What tuning have you done to Postgres and what is your regular maintenance schedule? Although my needs are different, it would be nice to get some idea what others are doing. thanks, jbw
Re: [Dbmail] PostgreSQL tuning for dbmail
At 05:16 PM 3/12/2002 +1100, Philip Warner wrote: set max_fsm_pages to 4 vacuum every two hours vacuum 'users' every 5 min analyze every hour dbmail-maintenance -p -d -f daily. I should have mentioned two things: (a) with the above settings, the server load is minimal (1), CPU is 80-90% idle, and response times are good. (b) there are plans to automate large amounts of the tuning in the next version or two (at least the vacuuming). Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
[Dbmail] Error in dbmail-imapd
Using dbmail-imapd with a german outlook express 6.0 makes outlook waiting forever for a response... while trying to create standard folders when initializing the imap account on first login... Log says: Dec 3 12:45:50 dnsc2 dbmail/imap4[4028]: COMMAND: [0039 CREATE EntwAPw-rfe] How and where to fix? Greetings from munich/germany Hans
[Dbmail] Outlook Express Special Char in Foldernames solution
Append an ampersand to the following array in imap4.c const char AcceptedMailboxnameChars[] = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-=/ _; Hans
[Dbmail] Error in dbmail-imapd
After testing i found one more character to add: , and It seems as if oe is escaping special chars with xxx- and x,x- ... so array in imap4.c must look like this: const char AcceptedMailboxnameChars[] = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-=/ _,; Hans
Re: [Dbmail] Error in dbmail-imapd
Not sure if this is what you need to reference, but http://www.faqs.org/rfcs/rfc2060.html section 5.1.3. Mailbox International Naming Convention has a pretty good summary of acceptable mailbox name characters. On Wed, 2002-12-04 at 03:22, Hans Kula wrote: Hi Roel, The latest CVS contains the following array: const char AcceptedMailboxnameChars[] = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-=/ _.; The char , is missing...this is for the german szml; char. regards hans - Original Message - From: Roel Rozendaal - ICS [EMAIL PROTECTED] To: dbmail@dbmail.org Sent: Tuesday, December 03, 2002 3:08 PM Subject: Re: [Dbmail] Error in dbmail-imapd Hi hans, could you try the latest CVS? It should be fixed by now. regards roel Hans Kula heeft op dinsdag, 3 dec 2002 om 14:58 (Europe/Amsterdam) het volgende geschreven: EntwAPw-rfe ___ Dbmail mailing list Dbmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail ___ Dbmail mailing list Dbmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail -- Richard Barrington [EMAIL PROTECTED]
Re: [Dbmail] ANNOUNCEMENT: DBMAIL 1.0!!!
Dont' forget to announce on freshmeat; the rc4 announcement never made it! (so, to be sly, you could announce rc4 today, and announce 1.0 later this week... just to get a bit more front page time to spread the word ;-) Aaron On Tue, 3 Dec 2002, ICS Helpdesk wrote: Yes! Finally :) This is the official announcement of dbmail 1.0 stable! You can download it at our all new dbmail website (www.dbmail.org). Major updates: - imap commandline scanner is now fully RFC compatible - new server code for both imap and pop servers - many little bugfixes Give dbmail a testrun and let us know how she runs! Best regards, ICS Dbmail team (Roel, Eelco) ___ Dbmail mailing list Dbmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] The Future
The autoconf fixes should have went in before 1.0, as it is now the autconf stuff shipped with 1.0 doesn't coexist well with non autoconf builds and is partially broken. They definately need to go in botht he 1.0 and 1.1 branches. They really should have went in at 1.0 or had autoconf removed before 1.0. Hi Ryan, We tried to incorporate autoconf in 1.0 but unfortunatly our autoconf guy is on a 6 month leave and Roel and I are working on other stuff. To fill in for the miss we incorporated a build script which should be sufficient for now. It would have taken too long to fully incorporate it in the main source tree before 1.0. We will however put it in 1.1. Best regards, Eelco -- Ryan Butler [EMAIL PROTECTED] ADI Internet Solutions http://dbmail.adiis.net - dbmail patches ___ Dbmail mailing list Dbmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail _ E.J.A. van Beek ICT Manager ICS T: +31 30 2322878 F: +31 30 2322305 PGP-key: www.ic-s.nl/keys/eelco.txt
Re: [Dbmail] The Future
On Tue, 2002-12-03 at 14:05, Eelco van Beek - ICS wrote: Hi Ryan, We tried to incorporate autoconf in 1.0 but unfortunatly our autoconf guy is on a 6 month leave and Roel and I are working on other stuff. To fill in for the miss we incorporated a build script which should be sufficient for now. It would have taken too long to fully incorporate it in the main source tree before 1.0. We will however put it in 1.1. Best regards, Eelco I guess I'm really confused. I wasn't aware you had an autoconf guy, which is why I submitted the autoconf stuff that is currently in 1.0 and cvs Since then I've submitted a couple of patches which would have allowed dbmail to use either the old style build, or the autoconf build interchangeably on the source (http://dbmail.adiis.net/files/Makefile_includes.patch) and some fixups for autoconf bugs (http://dbmail.adiis.net/files/dbmail_must_choose_sql_backend.patch). Had these been applied dbmail could have used either build system interchangeably. Instead, the 1.0 tarball contains a mostly broken without tinkering autoconf system that most people will probably try because they see ./configure :) If you have an autoconf guy who is going to redo the work currently there, or if you weren't planning on using my work, I don't understand why it was distributed with 1.0, and if you are planning to use the current autoconf system, I don't understand why the two non code invasive patches that would have put a working autoconf system weren't applied. -- Ryan Butler [EMAIL PROTECTED] ADI Internet Solutions http://dbmail.adiis.net - dbmail patches
[Dbmail] All empty document
I just did a CVS update of dbmail 1.0 and all files in /dbmail/sql/mysql are empty there is a small typing error in the INSTALL file the line mysql -u root -p sql/mysql/create_tables.sql ( IS ) mysql -u root -p sql/mysql/create_tables.mysql( SHOULD BE )
