Hi Mark! >>> It's getting even worse. The following SQL will not work... >>> ...as MySQL 5.1 doesn't support foreign keys on partitioned tables. >> It would be nice to have these foreign key constraints, but as they >> are IMO solely needed for garbage collection (please correct me, if >> I'm wrong) I can live without them - DROP PARTITION does a better >> job and none of my other applications are relaying on these keys. > > True. The FOREIGN KEY is only used for purging (ON DELETE RESTRICT) > and can be dropped if other purging methods are used, like dropping > a partition, or even just deleting records, individually for each table > (without referencing other tables) based on partition_tag only.
Thought so. Thanks for confirmation! >> error message: >> > 451 4.5.0 Error in processing, id=31462-06, sql-enter FAILED: >> > find_or_save_addr: failed to insert addr [EMAIL PROTECTED]: sql exec: >> > err=1022, 23000, DBD::mysql::st execute failed: Can't write; >> > duplicate key in table 'maddr' at (eval 96) line 166, <GEN16> line >> > 2157. at (eval 97) line 112, <GEN16> line 2157. (in reply to end of >> > DATA command) > Is it still happening? Yes, but really seldom as maddr quickly filled up (~ 300,000 records on first day) - but it still happens about 20 times a day (did a quick grep on my logs). > Amavisd uses the following logic when finding/inserting e-mail > addresses in table maddr: > ... > Now, if this second SELECT failed to find a record, only then > the failure of step 2 is reported - which is what you are seeing. > I'm not sure what sequence of events would lead to this in a > partitioned database. Neither am I. Race condition seems to occur each time an address not yet existent in my maddr-table is used as sender for more than one mail "simultaneously" - and multiple amavisd-instances are therefore processing it. I'm not sure whether it is related to the quoted MySQL bug - but it could really be something like that - if both threads are getting the same autoincremental id - and BOTH INSERT's are therefore failing. Such behaviour could match your description of amavisd-new's logic. Don't know whether this is true - any idea how to debug it without wasting too much time? > I'm grateful that you are willing to invest time and effort > to pave the path for others to follow. Lucky them ;-) Regards, Thomas Gelf ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
