Skip site navigation (1) Skip section navigation (2)

Re: anoncvs still slow

From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: anoncvs still slow
Date: 2006-05-29 18:00:44
Message-ID: 20060529150007.F1114@ganymede.hub.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, 29 May 2006, Magnus Hagander wrote:

>>> The quick fix is, as I wrote in one of my earlier mails, to
>> configure
>>> svr1 not to tell svr4 to *retry delivery*, but to just junk
>> the mail
>>> right away. It'll still cause joe-job style problems, but it won't
>>> load up the queue for days.
>>
>> But, from my look at the queue on svr4, this is already being
>> done ... the queue contains a bunch of MAILER-DAEMON bounces
>> back for 'recipient unknown', which is what is supposed to happen ...
>
> That's because I've deleted thousands of emails already, and run the
> delete script once every hour or so in order to keep it living.
> (I bet your "mailq" command didn't take almost an hour - that's what it
> did when I ran it this morning)
>
> Run something like:
> mailq | grep "Recipient address rejected"

I thought that the above was supposed to be a perm error, not temp?  Does 
anyone know what I need to set in postfix on svr1 to change it to a perm?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org                              MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664

In response to

Responses

pgsql-hackers by date

Next:From: Thomas HallgrenDate: 2006-05-29 18:02:55
Subject: Re: Proposal for debugging of server-side stored procedures
Previous:From: Magnus HaganderDate: 2006-05-29 17:46:07
Subject: Re: anoncvs still slow

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group