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

Re: anoncvs still slow

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Cc: "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 17:46:07
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCEA0F9C1@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-hackers
> > 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"

This will currently show 283 emails, all backed to svr1.

To clean up the queue (of this type of emails only), run 
mailq |./t.pl |postsuper -d -

from roots homedir.


The mails you are seeing are the ones generated after the other ones
have been sitting in the queue for a couple of days. They were also in
the thousands before, but since I try to cut down the queue at every
chance I get now, it usually doesn't get that far, so they don't
increase that much.


> but, your point about the greylisting makes sense ... will 
> work on implementing that one tonight ...

Great.

//Magnus

Responses

pgsql-hackers by date

Next:From: Marc G. FournierDate: 2006-05-29 18:00:44
Subject: Re: anoncvs still slow
Previous:From: Marc G. FournierDate: 2006-05-29 17:34:36
Subject: Re: anoncvs still slow

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