Menu
▾
▴
sqlgrey-users
|
From: Andrew D. <and...@gm...> - 2007-02-03 16:17:52
|
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 there is no result, postfix lets the mail through? Here's what my smtpd_recipient_restrictions looks like today. Thanks for the help. smtpd_recipient_restrictions = reject_non_fqdn_recipient reject_non_fqdn_sender reject_unknown_recipient_domain permit_mynetworks permit_tls_clientcerts permit_sasl_authenticated reject_unauth_destination reject_unauth_pipelining reject_invalid_hostname check_recipient_access hash:/etc/postfix/oldusers check_policy_service inet:127.0.0.01:2501 check_recipient_access hash:/etc/postfix/roleaccount_exceptions reject_non_fqdn_hostname check_sender_mx_access cidr:/etc/postfix/bogus_mx check_sender_access hash:/etc/postfix/rhsbl_sender_exceptions permit -- Andrew Diederich |
|
From: Riaan K. <ria...@gm...> - 2007-02-04 17:55:50
|
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 > 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.. Here's what Wietse has to say on the topic: http://archives.neohapsis.com/archives/postfix/2006-12/1573.html 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 |
|
From: Dave S. <dst...@ma...> - 2007-02-04 18:28:51
|
Andrew, =20 It doesn't actually reject the email, it just defers it with a "450" = warning. However, it would be nice if it allowed the email through, on the = logic that if it can't filter, it should "pass by default". =20 This certainly is a problem on the Postfix end, and nothing I have ever = seen can solve it other than a fix and a recompile of postfix. =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 |
|
From: Andrew D. <and...@gm...> - 2007-02-05 03:11:52
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title></title>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<meta http-equiv=3D"Content-Style-Type" content=3D"text/css">
<style type=3D"text/css"><!--
body {
margin: 5px 5px 5px 5px;
background-color: #ffffff;
}
/* ---------- Text Styles ---------- */
hr { color: #000000}
body, table /* Normal text */
{
font-size: 9pt;
font-family: 'Courier New';
font-style: normal;
font-weight: normal;
color: #000000;
text-decoration: none;
}
span.rvts1 /* Heading */
{
font-size: 10pt;
font-family: 'Arial';
font-weight: bold;
color: #0000ff;
}
span.rvts2 /* Subheading */
{
font-size: 10pt;
font-family: 'Arial';
font-weight: bold;
color: #000080;
}
span.rvts3 /* Keywords */
{
font-size: 10pt;
font-family: 'Arial';
font-style: italic;
color: #800000;
}
a.rvts4, span.rvts4 /* Jump 1 */
{
font-size: 10pt;
font-family: 'Arial';
color: #008000;
text-decoration: underline;
}
a.rvts5, span.rvts5 /* Jump 2 */
{
font-size: 10pt;
font-family: 'Arial';
color: #008000;
text-decoration: underline;
}
span.rvts6
{
font-family: 'tahoma';
font-weight: bold;
color: #ffffff;
background-color: #0000ff;
}
span.rvts7
{
font-family: 'tahoma';
}
a.rvts8, span.rvts8
{
font-family: 'tahoma';
color: #0000ff;
text-decoration: underline;
}
span.rvts9
{
font-family: 'tahoma';
font-weight: bold;
}
span.rvts10
{
}
span.rvts11
{
font-size: 8pt;
font-family: 'arial';
font-style: italic;
color: #c0c0c0;
}
/* ---------- Para Styles ---------- */
p,ul,ol /* Paragraph Style */
{
text-align: left;
text-indent: 0px;
padding: 0px 0px 0px 0px;
margin: 0px 0px 0px 0px;
}
.rvps1 /* Centered */
{
text-align: center;
}
--></style>
</head>
<body>
<p>On Sunday, February 4, 2007, 11:27:38 AM, Dave Strickler wrote:</p>
<p><br></p>
<div><table border=3D0 cellpadding=3D1 cellspacing=3D2 style=3D"border-colo=
r: #000000; border-style: solid;">
<tr valign=3Dtop>
<td width=3D11 style=3D"background-color: #0000ff;">
<p><span class=3Drvts6>></span></p>
</td>
<td width=3D709 style=3D"background-color: #ffffff;">
<p><span class=3Drvts7>Andrew,</span></p>
<p><span class=3Drvts7> </span></p>
<p><span class=3Drvts7>It doesn't actually reject the email, it just defers=
it with a "450" warning. However, it would be nice if it allowed the email=
through, on the logic that if it can't filter, it should "pass by default"=
.</span></p>
<p><span class=3Drvts7> </span></p>
<p><span class=3Drvts7>This certainly is a problem on the Postfix end, and =
nothing I have ever seen can solve it other than a fix and a recompile of p=
ostfix.</span></p>
<p><span class=3Drvts7> </span></p>
</td>
</tr>
</table>
</div>
<p><br></p>
<p>That's what I needed to know. Thanks.</p>
<p><br></p>
<p><span class=3Drvts11>-- </span></p>
<p><span class=3Drvts11>Best regards,</span></p>
<p><span class=3Drvts11> Andrew Diederich </span></p>
</body></html>
|
|
From: Dan F. <da...@ha...> - 2007-02-05 04:55:29
|
> This certainly is a problem on the Postfix end, and nothing I have ever seen can > solve it other than a fix and a recompile of postfix. > I thought (several times) about making a hyper small-and-clean "proxy" daemon to handle to connection between postfix and the policy daemons.. If the small proxy-daemon could be made robust enough, it could return "dunno" upon "no answer" from the policy-daemons. This would be a somewhat unclean hack and im unsure if it would be too unclean to be of any use. Just my 5 cents of thought. - Dan |
|
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 |
|
From: Riaan K. <ria...@gm...> - 2007-02-04 19:49:12
|
On 04/02/07, Dave Strickler <dst...@ma...> wrote: > > Riaan, > > 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? > > Dave Strickler > I'm no expert, but I'm a fair googler! This page has an interesting paragraph on this topic: http://www.saturn5.com/~jwb/dbi-performance.html "Every time DBI's prepare method is called, DBI parses the SQL command looking for placeholder strings, and does some housekeeping work. Worse, a context has to be built on the client and server sides of the connection which the database will use to refer to the statement. These things take time, and by eliminating these steps the time can be saved." I have no idea what the real world penalty is for not using prepare_cached in sqlgrey (or any) context, but for me it was either that or have a major memory leak. (In my DBI implementation, prepare_cached's cache didn't seem to know about expiring old stuff, so the decision was easy..) This is a database and setup specific thing, so all I'm suggesting is that if you're seeing a memory leak, consider the possibility of a faulty cache implementation in your database library code. I've had little success in finding information about prepare_cache's inner workings.. how long cache elements stay valid, how they expire, how far it will grow, or even what the expected performance gains might be, what (if any) controls there are, how different databases are affected.. anybody that could shed some light here, I'd appreciate it too! Anyway, it did strike me that if the query changes, a different handle gets returned, therefore any query that contains timestamp calculations outside of a bound parameter will not benefit from the handle cache... One thing I'll say for sure Dave, it works on a completely different level from your memcache project (sql handle cache vs. data cache). For a specific sql statement, memcache could hold a few items already, and prepare_cached could theoretically help a bit if new data is fetched from DB using that same query. So, they should co-exist happily! Riaan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X