From: Dave S. <dst...@ma...> - 2007-02-04 18:33:54
|
Riaan, =20 Not being a Perl programmer on this end, can you explain the downside of = not using "prepair_cached"? I would assume this means it would need to = reconnect to the SQL server, or am I missing the point? What does = prepair_cached buy you in performance? =20 Dave Strickler MailWise LLC 617-933-5810 (direct) www.mailwise.com ( http://www.mailwise.com/ ) "Intelligent E-mail Protection" >>> "Riaan Kok" <ria...@gm...> 12:55 PM Sunday, February 04, 2007 = >>> On 03/02/07, Andrew Diederich <and...@gm... > wrote: Slightly off-topic: I have to restart sqlgrey fairly often because of a memory leak in the non-sqlgrey DBI portion. I've seen that if sqlgrey is down, because postfix can't connect to the daemon, it rejects the mail. Is it possible to, say, add DUNNO somehow so if=20 there is no result, postfix lets the mail through? Here's what my smtpd_recipient_restrictions looks like today. Thanks for the help. -- Andrew Diederich We're out of luck there..=20 Here's what Wietse has to say on the topic: http://archives.neohapsis.com/archives/postfix/2006-12/1573.html=20 However, my DBI setup also had a memory leak, which I traced to a = not-quite-kosher prepare_cached implementation down the line. Replacing = "prepare_cached" in sqlgrey with "prepare" globally fixed it for me. = Maybe just maybe it helps for somebody else as well.. good luck, Riaan This message has been certified virus-free by MailWise Filter - The real-ti= me, intelligent, e-mail firewall used to scan inbound and outbound messages = for SPAM, Viruses and Content. =0A=0A For more information, please visit: http:= //www.mailwise.com=0A |