Re: anoncvs still slow
От | Magnus Hagander |
---|---|
Тема | Re: anoncvs still slow |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCEA0F9C1@algol.sollentuna.se обсуждение исходный текст |
Ответ на | anoncvs still slow (Michael Fuhr <mike@fuhr.org>) |
Ответы |
Re: anoncvs still slow
|
Список | 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
В списке pgsql-hackers по дате отправления: