agora inbox for [email protected]
help / color / mirror / Atom feedanoncvs still slow
23+ messages / 12 participants
[nested] [flat]
* anoncvs still slow
@ 2006-05-27 19:06 Michael Fuhr <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Michael Fuhr @ 2006-05-27 19:06 UTC (permalink / raw)
To: pgsql-hackers
anoncvs (svr4, 66.98.251.159) is still slow responding to "cvs update";
it's been spotty for about a week now. Tcpdump shows connections being
established but then long delays for ACKs, sometimes long enough for cvs
to time out. Any updates on what's going on?
--
Michael Fuhr
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-27 20:45 Tom Lane <[email protected]>
parent: Michael Fuhr <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Tom Lane @ 2006-05-27 20:45 UTC (permalink / raw)
To: Michael Fuhr <[email protected]>; +Cc: pgsql-hackers; Magnus Hagander <[email protected]>
Michael Fuhr <[email protected]> writes:
> anoncvs (svr4, 66.98.251.159) is still slow responding to "cvs update";
> it's been spotty for about a week now. Tcpdump shows connections being
> established but then long delays for ACKs, sometimes long enough for cvs
> to time out. Any updates on what's going on?
Magnus apparently knows what the problem is:
http://archives.postgresql.org/pgsql-hackers/2006-05/msg01002.php
but I haven't seen any of the "other mails" he mentioned.
regards, tom lane
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-27 21:31 Marc G. Fournier <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Marc G. Fournier @ 2006-05-27 21:31 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Fuhr <[email protected]>; pgsql-hackers; Magnus Hagander <[email protected]>
On Sat, 27 May 2006, Tom Lane wrote:
> Michael Fuhr <[email protected]> writes:
>> anoncvs (svr4, 66.98.251.159) is still slow responding to "cvs update";
>> it's been spotty for about a week now. Tcpdump shows connections being
>> established but then long delays for ACKs, sometimes long enough for cvs
>> to time out. Any updates on what's going on?
>
> Magnus apparently knows what the problem is:
> http://archives.postgresql.org/pgsql-hackers/2006-05/msg01002.php
> but I haven't seen any of the "other mails" he mentioned.
svr4 / anoncvs needs a major upgrade ... the problem is that the only part
of that vServer that I know nothing about is the bittorrent stuff, which,
in itself, needs an upgrade ... I sent a note to Magnus that, whenever
he's ready with the bittorrent stuff, I can do the rest of the upgrade, so
its in his court right now :)
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [email protected] MSN . [email protected]
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-28 19:25 Magnus Hagander <[email protected]>
0 siblings, 3 replies; 23+ messages in thread
From: Magnus Hagander @ 2006-05-28 19:25 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; Tom Lane <[email protected]>; +Cc: Michael Fuhr <[email protected]>; pgsql-hackers
> >> anoncvs (svr4, 66.98.251.159) is still slow responding to "cvs
> >> update"; it's been spotty for about a week now. Tcpdump shows
> >> connections being established but then long delays for ACKs,
> >> sometimes long enough for cvs to time out. Any updates on
> what's going on?
> >
> > Magnus apparently knows what the problem is:
> > http://archives.postgresql.org/pgsql-hackers/2006-05/msg01002.php
> > but I haven't seen any of the "other mails" he mentioned.
Right, those mails were sent in private to Marc, because they outline
some fairly severe (IMHO) configuration errors on svr4 and at least one
other postgresql.org mailserver, that is the main reason behind the
problems. I didn't want those details to go out public and be archived.
> svr4 / anoncvs needs a major upgrade ... the problem is that
> the only part of that vServer that I know nothing about is
> the bittorrent stuff, which, in itself, needs an upgrade ...
> I sent a note to Magnus that, whenever he's ready with the
> bittorrent stuff, I can do the rest of the upgrade, so its in
> his court right now :)
Um, *what*?
AFAICS, this is caused by the machine attempting to relay thousands and
thousands of spam emails (some quick checked showed a rate of about 1
spam / 5 seconds enytering the queue - and I know I deleted almost
20,000 from the queue)
This is a *configuration error*. if we *wanted* all this spam to be
relayed, it would be a performance problem. But to be efficient, the
spam has to be rejected *before* it enters the system. I've suggested a
couple of different things to be done to fix or at least decrease this
problem. From what I can tell, none have been implemented.
Now for the other problems, I propose the following:
For bittorrent, I propose we take it out. We've suggested it before, I
don't recall receiving any real requests to keep it, and IMHO it's way
much more pain than it's worth. Therefor, unless someone objects, I'll
pull the bittorrent links from the website in a couple of days, and then
we can just remove it from the server.
Also, if anoncvs is a problem that we need quickly fixed, can we mov eit
quickly to a different server. Say Ferengi, which has both bandwidth and
horsepower to spare in loads. Do we require some special-special version
of cvs, or just plain cvs?
//Magnus
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-28 19:56 Devrim GUNDUZ <[email protected]>
parent: Magnus Hagander <[email protected]>
2 siblings, 0 replies; 23+ messages in thread
From: Devrim GUNDUZ @ 2006-05-28 19:56 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
Hi,
On Sun, 2006-05-28 at 21:25 +0200, Magnus Hagander wrote:
> For bittorrent, I propose we take it out. We've suggested it before, I
> don't recall receiving any real requests to keep it, and IMHO it's way
> much more pain than it's worth. Therefor, unless someone objects, I'll
> pull the bittorrent links from the website in a couple of days, and
> then we can just remove it from the server.
Please go for it.
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-28 23:42 Joshua D. Drake <[email protected]>
parent: Magnus Hagander <[email protected]>
2 siblings, 0 replies; 23+ messages in thread
From: Joshua D. Drake @ 2006-05-28 23:42 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
> For bittorrent, I propose we take it out. We've suggested it before, I
> don't recall receiving any real requests to keep it, and IMHO it's way
> much more pain than it's worth.
We received a couple of requests for the torrent on the IRC channel when
the update was released. Just FYI.
Therefor, unless someone objects, I'll
> pull the bittorrent links from the website in a couple of days, and then
> we can just remove it from the server.
>
>
> Also, if anoncvs is a problem that we need quickly fixed, can we mov eit
> quickly to a different server. Say Ferengi, which has both bandwidth and
> horsepower to spare in loads. Do we require some special-special version
> of cvs, or just plain cvs?
CMD has a spare machine we can host it on as well if you like.
Sincerely,
Joshua D. Drake
>
> //Magnus
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [email protected] so that your
> message can get through to the mailing list cleanly
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-29 17:14 Marc G. Fournier <[email protected]>
parent: Magnus Hagander <[email protected]>
2 siblings, 1 reply; 23+ messages in thread
From: Marc G. Fournier @ 2006-05-29 17:14 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
On Sun, 28 May 2006, Magnus Hagander wrote:
> AFAICS, this is caused by the machine attempting to relay thousands and
> thousands of spam emails (some quick checked showed a rate of about 1
> spam / 5 seconds enytering the queue - and I know I deleted almost
> 20,000 from the queue)
And how exactly would you like me to fix *that*? The reason those were in
the queue is because svr4 is a legit MX record for the mailing lists ...
the messages are being delivered into svr4's mail queue, and
mail.postgresql.org subsequently refusing htem because they are for
invalid addresses ...
If I remove svr4 as an MX record, its just going to move to a different
machine ...
So, how exactly would you like me to "fix" that problem?
> For bittorrent, I propose we take it out. We've suggested it before, I
> don't recall receiving any real requests to keep it, and IMHO it's way
> much more pain than it's worth. Therefor, unless someone objects, I'll
> pull the bittorrent links from the website in a couple of days, and then
> we can just remove it from the server.
That works for me ... let me know once its is down, and then I can easily
do the upgrade ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [email protected] MSN . [email protected]
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-29 17:27 Magnus Hagander <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Magnus Hagander @ 2006-05-29 17:27 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
> > AFAICS, this is caused by the machine attempting to relay thousands
> > and thousands of spam emails (some quick checked showed a rate of
> > about 1 spam / 5 seconds enytering the queue - and I know I deleted
> > almost 20,000 from the queue)
>
> And how exactly would you like me to fix *that*? The reason
> those were in the queue is because svr4 is a legit MX record
> for the mailing lists ...
> the messages are being delivered into svr4's mail queue, and
> mail.postgresql.org subsequently refusing htem because they
> are for invalid addresses ...
>
> If I remove svr4 as an MX record, its just going to move to a
> different machine ...
>
> So, how exactly would you like me to "fix" that problem?
The complete fix is of course to apply the same ingress filtering on all
machines.
If that's not possible, do it as much as possible. As the email
addresses existing on svr1 is fairly static, it shouldn't be too hard to
teach svr4 (and other MXen if there are any) about them.
To make graylisting properly effective that also needs to be applied on
all entrypoints, otherwise svr4 will just solve the problems for the
spammers who have software that won't retry.
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.
> > For bittorrent, I propose we take it out. We've suggested
> it before, I
> > don't recall receiving any real requests to keep it, and
> IMHO it's way
> > much more pain than it's worth. Therefor, unless someone
> objects, I'll
> > pull the bittorrent links from the website in a couple of days, and
> > then we can just remove it from the server.
>
> That works for me ... let me know once its is down, and then
> I can easily do the upgrade ...
I'll give it a day or two more for people to complain, and then junk it.
//Magnus
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-29 17:34 Marc G. Fournier <[email protected]>
parent: Magnus Hagander <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Marc G. Fournier @ 2006-05-29 17:34 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; 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 ...
but, your point about the greylisting makes sense ... will work on
implementing that one tonight ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [email protected] MSN . [email protected]
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-29 17:46 Magnus Hagander <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Magnus Hagander @ 2006-05-29 17:46 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; 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
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-29 18:00 Marc G. Fournier <[email protected]>
parent: Magnus Hagander <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Marc G. Fournier @ 2006-05-29 18:00 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; 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 . [email protected] MSN . [email protected]
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-29 18:20 Magnus Hagander <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Magnus Hagander @ 2006-05-29 18:20 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; 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"
>
> 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?
Yes, htat's what I sent before :-)
c) Change svr1 parameters to:
unknown_relay_recipient_reject_code = 550
and
unknown_local_recipient_reject_code = 550
//Magnus
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-29 18:21 Andrew Sullivan <[email protected]>
parent: Marc G. Fournier <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Andrew Sullivan @ 2006-05-29 18:21 UTC (permalink / raw)
To: pgsql-hackers
On Mon, May 29, 2006 at 03:00:44PM -0300, Marc G. Fournier wrote:
> >
> >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?
Do you have soft bounce turned on? A mailbox unavailable message
should be a 550 error. Or is the problem that the relay gets back
the rejection, and then queues a message to the originating mailer
(which was, of course, a drone, and therefore won't be available)?
The latter case will _also_ eat up a ton of resources.
Unfortunately, there's no standards-compliant way to drop such
connections on the floor instead of erroring, once you've accepted
the mail.
Better to reject at the time of connection, which is what the
local_recipient_maps setting is for.
A
--
Andrew Sullivan | [email protected]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-29 18:26 Magnus Hagander <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Magnus Hagander @ 2006-05-29 18:26 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
> > > 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?
>
> Yes, htat's what I sent before :-)
>
> c) Change svr1 parameters to:
> unknown_relay_recipient_reject_code = 550 and
> unknown_local_recipient_reject_code = 550
By the way, the proper way to fix it it o use a relay_recipient_map. To
this map, add all the users that are valid in postgresql.org, and
install it on svr4. Then svr4 will reject the connections *before* it
queues up the mail, and it'll also get rid of the incorrect bounces.
//Magnus
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-30 17:52 Jim C. Nasby <[email protected]>
parent: Marc G. Fournier <[email protected]>
0 siblings, 2 replies; 23+ messages in thread
From: Jim C. Nasby @ 2006-05-30 17:52 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
On Mon, May 29, 2006 at 02:14:42PM -0300, Marc G. Fournier wrote:
> On Sun, 28 May 2006, Magnus Hagander wrote:
>
> >AFAICS, this is caused by the machine attempting to relay thousands and
> >thousands of spam emails (some quick checked showed a rate of about 1
> >spam / 5 seconds enytering the queue - and I know I deleted almost
> >20,000 from the queue)
>
> And how exactly would you like me to fix *that*? The reason those were in
> the queue is because svr4 is a legit MX record for the mailing lists ...
> the messages are being delivered into svr4's mail queue, and
> mail.postgresql.org subsequently refusing htem because they are for
> invalid addresses ...
>
> If I remove svr4 as an MX record, its just going to move to a different
> machine ...
>
> So, how exactly would you like me to "fix" that problem?
Postfix allows you to specify a list of valid email addresses. It should
be a simple matter of specifying what all the valid mailing list email
addresses are.
--
Jim C. Nasby, Sr. Engineering Consultant [email protected]
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-30 18:01 Andrew Dunstan <[email protected]>
parent: Jim C. Nasby <[email protected]>
1 sibling, 2 replies; 23+ messages in thread
From: Andrew Dunstan @ 2006-05-30 18:01 UTC (permalink / raw)
To: Jim C. Nasby <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Magnus Hagander <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
Jim C. Nasby wrote:
> Postfix allows you to specify a list of valid email addresses. It should
> be a simple matter of specifying what all the valid mailing list email
> addresses are.
>
umm ... we allow non-subscribers to post, the posts just have to be
approved. How would we still do that?
cheers
andrew
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-30 18:12 Alvaro Herrera <[email protected]>
parent: Andrew Dunstan <[email protected]>
1 sibling, 1 reply; 23+ messages in thread
From: Alvaro Herrera @ 2006-05-30 18:12 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Jim C. Nasby <[email protected]>; Marc G. Fournier <[email protected]>; Magnus Hagander <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
Andrew Dunstan wrote:
> Jim C. Nasby wrote:
> >Postfix allows you to specify a list of valid email addresses. It should
> >be a simple matter of specifying what all the valid mailing list email
> >addresses are.
>
> umm ... we allow non-subscribers to post, the posts just have to be
> approved. How would we still do that?
What's checked is the recipient, not the sender.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-30 18:16 Andrew Dunstan <[email protected]>
parent: Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Andrew Dunstan @ 2006-05-30 18:16 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; Jim C. Nasby <[email protected]>; Marc G. Fournier <[email protected]>; Magnus Hagander <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
>> Jim C. Nasby wrote:
>>
>>> Postfix allows you to specify a list of valid email addresses. It should
>>> be a simple matter of specifying what all the valid mailing list email
>>> addresses are.
>>>
>> umm ... we allow non-subscribers to post, the posts just have to be
>> approved. How would we still do that?
>>
>
> What's checked is the recipient, not the sender.
>
>
ah, ok. sorry for the noise.
cheers
andrew
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-30 19:21 Marc G. Fournier <[email protected]>
parent: Jim C. Nasby <[email protected]>
1 sibling, 1 reply; 23+ messages in thread
From: Marc G. Fournier @ 2006-05-30 19:21 UTC (permalink / raw)
To: Jim C. Nasby <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Magnus Hagander <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
On Tue, 30 May 2006, Jim C. Nasby wrote:
> On Mon, May 29, 2006 at 02:14:42PM -0300, Marc G. Fournier wrote:
>> On Sun, 28 May 2006, Magnus Hagander wrote:
>>
>>> AFAICS, this is caused by the machine attempting to relay thousands and
>>> thousands of spam emails (some quick checked showed a rate of about 1
>>> spam / 5 seconds enytering the queue - and I know I deleted almost
>>> 20,000 from the queue)
>>
>> And how exactly would you like me to fix *that*? The reason those were in
>> the queue is because svr4 is a legit MX record for the mailing lists ...
>> the messages are being delivered into svr4's mail queue, and
>> mail.postgresql.org subsequently refusing htem because they are for
>> invalid addresses ...
>>
>> If I remove svr4 as an MX record, its just going to move to a different
>> machine ...
>>
>> So, how exactly would you like me to "fix" that problem?
>
> Postfix allows you to specify a list of valid email addresses. It should
> be a simple matter of specifying what all the valid mailing list email
> addresses are.
The list of email addresses changes over time ... so whomever creates a
new mailbox would need to remember to add it on the MX servers as well ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [email protected] MSN . [email protected]
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-30 21:16 Martijn van Oosterhout <[email protected]>
parent: Andrew Dunstan <[email protected]>
1 sibling, 0 replies; 23+ messages in thread
From: Martijn van Oosterhout @ 2006-05-30 21:16 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Jim C. Nasby <[email protected]>; Marc G. Fournier <[email protected]>; Magnus Hagander <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
On Tue, May 30, 2006 at 02:01:07PM -0400, Andrew Dunstan wrote:
> Jim C. Nasby wrote:
> >Postfix allows you to specify a list of valid email addresses. It should
> >be a simple matter of specifying what all the valid mailing list email
> >addresses are.
> >
>
> umm ... we allow non-subscribers to post, the posts just have to be
> approved. How would we still do that?
I'm assuming we're talking about a list of valid To: addresses, not From:
addresses. That list should be fairly short...
Have a nice day,
--
Martijn van Oosterhout <[email protected]> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
Attachments:
[application/pgp-signature] signature.asc (189B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-30 23:02 Jim C. Nasby <[email protected]>
parent: Marc G. Fournier <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Jim C. Nasby @ 2006-05-30 23:02 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
On Tue, May 30, 2006 at 04:21:46PM -0300, Marc G. Fournier wrote:
> On Tue, 30 May 2006, Jim C. Nasby wrote:
>
> >On Mon, May 29, 2006 at 02:14:42PM -0300, Marc G. Fournier wrote:
> >>On Sun, 28 May 2006, Magnus Hagander wrote:
> >>
> >>>AFAICS, this is caused by the machine attempting to relay thousands and
> >>>thousands of spam emails (some quick checked showed a rate of about 1
> >>>spam / 5 seconds enytering the queue - and I know I deleted almost
> >>>20,000 from the queue)
> >>
> >>And how exactly would you like me to fix *that*? The reason those were in
> >>the queue is because svr4 is a legit MX record for the mailing lists ...
> >>the messages are being delivered into svr4's mail queue, and
> >>mail.postgresql.org subsequently refusing htem because they are for
> >>invalid addresses ...
> >>
> >>If I remove svr4 as an MX record, its just going to move to a different
> >>machine ...
> >>
> >>So, how exactly would you like me to "fix" that problem?
> >
> >Postfix allows you to specify a list of valid email addresses. It should
> >be a simple matter of specifying what all the valid mailing list email
> >addresses are.
>
> The list of email addresses changes over time ... so whomever creates a
> new mailbox would need to remember to add it on the MX servers as well ...
Depending on what the exact setup is, a friend has a script that should
help: http://slacker.com/~nugget/projects/postfixrelaymaps/
In a nutshell, it pulls from things like /etc/passwd on the master MX
and then pushes that info out to the slaves. It's written in perl, so it
should be easy to modify to pull from whatever source is necessary.
--
Jim C. Nasby, Sr. Engineering Consultant [email protected]
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: anoncvs still slow
@ 2006-05-31 00:32 Marc G. Fournier <[email protected]>
parent: Jim C. Nasby <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Marc G. Fournier @ 2006-05-31 00:32 UTC (permalink / raw)
To: Jim C. Nasby <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Magnus Hagander <[email protected]>; Tom Lane <[email protected]>; Michael Fuhr <[email protected]>; pgsql-hackers
On Tue, 30 May 2006, Jim C. Nasby wrote:
> Depending on what the exact setup is, a friend has a script that should
> help: http://slacker.com/~nugget/projects/postfixrelaymaps/
Thanks, but the script would involve a fair amount of work, since our mail
system isn't based on the pasword file :) But, I have setup a cron job
that runs every 30 minutes to generate a relay_users map for the MX server
that contains all valid mailboxes on the system ... if someone does notice
an email bouncing to somewhere that *should* work, please do let me know
...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [email protected] MSN . [email protected]
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
^ permalink raw reply [nested|flat] 23+ messages in thread
* [PATCH v47 8/9] Error out any process that would block at REPACK
@ 2026-03-25 19:35 Álvaro Herrera <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Álvaro Herrera @ 2026-03-25 19:35 UTC (permalink / raw)
Any process waiting on REPACK to release its lock would actually cause
it to deadlock when it tries to upgrade its lock to AEL, losing all work
done to that point. We avoid this by teaching the deadlock detector to
raise an error when this condition is detected.
---
src/backend/commands/repack.c | 52 ++++++++----
src/backend/storage/lmgr/deadlock.c | 15 ++++
src/include/storage/proc.h | 6 +-
src/test/modules/injection_points/Makefile | 1 +
.../expected/repack_deadlock.out | 63 ++++++++++++++
src/test/modules/injection_points/meson.build | 1 +
.../specs/repack_deadlock.spec | 83 +++++++++++++++++++
7 files changed, 202 insertions(+), 19 deletions(-)
create mode 100644 src/test/modules/injection_points/expected/repack_deadlock.out
create mode 100644 src/test/modules/injection_points/specs/repack_deadlock.spec
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index 9c807f75d71..3acb2e1d2ba 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -276,6 +276,16 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel)
/* Determine the lock mode to use. */
lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0);
+ /*
+ * If in concurrent mode, set the PROC_IN_CONCURRENT_REPACK flag. This
+ * makes the deadlock checker cause anyone that would conflict with us
+ * to error out. It's important to set this flag ahead of actually locking
+ * the relation; it won't of course affect anyone until we do have a lock
+ * that others can conflict with.
+ */
+ if ((params.options & CLUOPT_CONCURRENT) != 0)
+ MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK;
+
/*
* If a single relation is specified, process it and we're done ... unless
* the relation is a partitioned table, in which case we fall through.
@@ -476,11 +486,8 @@ RepackLockLevel(bool concurrent)
* If indexOid is InvalidOid, the table will be rewritten in physical order
* instead of index order.
*
- * Note that, in the concurrent case, the function releases the lock at some
- * point, in order to get AccessExclusiveLock for the final steps (i.e. to
- * swap the relation files). To make things simpler, the caller should expect
- * OldHeap to be closed on return, regardless CLUOPT_CONCURRENT. (The
- * AccessExclusiveLock is kept till the end of the transaction.)
+ * On return, OldHeap is closed but locked with AccessExclusiveLock - the lock
+ * will be released at end of the transaction.
*
* 'cmd' indicates which command is being executed, to be used for error
* messages.
@@ -512,10 +519,12 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid,
/*
* Make sure we're not in a transaction block.
*
- * The reason is that repack_setup_logical_decoding() could deadlock
- * if there's an XID already assigned. It would be possible to run in
- * a transaction block if we had no XID, but this restriction is
- * simpler for users to understand and we don't lose anything.
+ * The reason is that repack_setup_logical_decoding() could wait
+ * indefinitely for our XID to complete. (The deadlock detector would
+ * not recognize it because we'd be waiting for ourselves, i.e. no
+ * real lock conflict.) It would be possible to run in a transaction
+ * block if we had no XID, but this restriction is simpler for users
+ * to understand and we don't lose anything.
*/
PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)");
@@ -998,10 +1007,8 @@ rebuild_relation(Relation OldHeap, Relation index, bool verbose,
* Note that the worker has to wait for all transactions with XID
* already assigned to finish. If some of those transactions is
* waiting for a lock conflicting with ShareUpdateExclusiveLock on our
- * table (e.g. it runs CREATE INDEX), we can end up in a deadlock.
- * Not sure this risk is worth unlocking/locking the table (and its
- * clustering index) and checking again if it's still eligible for
- * REPACK CONCURRENTLY.
+ * table (e.g. it runs CREATE INDEX), it should encounter ERROR in the
+ * deadlock checking code.
*/
start_repack_decoding_worker(tableOid);
@@ -3090,7 +3097,16 @@ rebuild_relation_finish_concurrent(Relation NewHeap, Relation OldHeap,
LockRelationOid(OldHeap->rd_rel->reltoastrelid, AccessExclusiveLock);
/*
- * Tuples and pages of the old heap will be gone, but the heap will stay.
+ * Now that we have all access-exclusive locks on all relations, we no
+ * longer want other processes to error out when trying to acquire a
+ * conflicting lock. Therefore, unset our flag.
+ */
+ MyProc->statusFlags &= ~PROC_IN_CONCURRENT_REPACK;
+
+ /*
+ * Tuples and pages of the old heap will be gone, but the heap itself will
+ * stay. In order for predicate locks to continue to work, convert them
+ * to relation-level locks. We do this both for table and indexes.
*/
TransferPredicateLocksToHeapRelation(OldHeap);
foreach_ptr(RelationData, index, indexrels)
@@ -3287,9 +3303,11 @@ start_repack_decoding_worker(Oid relid)
/*
* The decoding setup must be done before the caller can have XID assigned
- * for any reason, otherwise the worker might end up in a deadlock,
- * waiting for the caller's transaction to end. Therefore wait here until
- * the worker indicates that it has the logical decoding initialized.
+ * for any reason, otherwise the worker might end up waiting for the
+ * caller's transaction to end. (Deadlock detector does not consider this
+ * a conflict because the worker is in the same locking group as the
+ * backend that launched it.) Therefore wait here until the worker
+ * indicates that it has the logical decoding initialized.
*/
ConditionVariablePrepareToSleep(&shared->cv);
for (;;)
diff --git a/src/backend/storage/lmgr/deadlock.c b/src/backend/storage/lmgr/deadlock.c
index b8962d875b6..3d3ec0da111 100644
--- a/src/backend/storage/lmgr/deadlock.c
+++ b/src/backend/storage/lmgr/deadlock.c
@@ -620,6 +620,21 @@ FindLockCycleRecurseMember(PGPROC *checkProc,
proc->statusFlags & PROC_IS_AUTOVACUUM)
blocking_autovacuum_proc = proc;
+ /*
+ * Similarly, if we note that we're blocked by some process
+ * running REPACK (CONCURRENTLY), just fail. That process
+ * is going to upgrade its lock at some point, and it would
+ * be inappropriate for any other process to cause that
+ * to fail.
+ */
+ if (checkProc == MyProc &&
+ proc->statusFlags & PROC_IN_CONCURRENT_REPACK)
+ ereport(ERROR,
+ errcode(ERRCODE_OBJECT_IN_USE),
+ errmsg("could not wait for concurrent REPACK"),
+ errdetail("Process %d waits for REPACK running on process %d",
+ MyProc->pid, proc->pid));
+
/* We're done looking at this proclock */
break;
}
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index 1dad125706e..8ad9718f3d6 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -69,10 +69,12 @@ struct XidCache
#define PROC_AFFECTS_ALL_HORIZONS 0x20 /* this proc's xmin must be
* included in vacuum horizons
* in all databases */
+#define PROC_IN_CONCURRENT_REPACK 0x40 /* REPACK (CONCURRENTLY) */
-/* flags reset at EOXact */
+/* flags reset at EOXact. A bit of a misnomer ... */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_SAFE_IC | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_IN_SAFE_IC | PROC_VACUUM_FOR_WRAPAROUND | \
+ PROC_IN_CONCURRENT_REPACK)
/*
* Xmin-related flags. Make sure any flags that affect how the process' Xmin
diff --git a/src/test/modules/injection_points/Makefile b/src/test/modules/injection_points/Makefile
index 2cd7d87c533..f7663859fe2 100644
--- a/src/test/modules/injection_points/Makefile
+++ b/src/test/modules/injection_points/Makefile
@@ -15,6 +15,7 @@ REGRESS_OPTS = --dlpath=$(top_builddir)/src/test/regress
ISOLATION = basic \
inplace \
repack \
+ repack_deadlock \
repack_toast \
syscache-update-pruned \
heap_lock_update
diff --git a/src/test/modules/injection_points/expected/repack_deadlock.out b/src/test/modules/injection_points/expected/repack_deadlock.out
new file mode 100644
index 00000000000..a86e4767536
--- /dev/null
+++ b/src/test/modules/injection_points/expected/repack_deadlock.out
@@ -0,0 +1,63 @@
+Parsed test spec with 2 sessions
+
+starting permutation: wait_before_lock add_column wakeup_before_lock check1
+injection_points_attach
+-----------------------
+
+(1 row)
+
+step wait_before_lock:
+ REPACK (CONCURRENTLY) repack_deadlock USING INDEX repack_deadlock_pkey;
+ <waiting ...>
+step add_column:
+ alter table repack_deadlock add column noise text;
+ <waiting ...>
+step add_column: <... completed>
+ERROR: could not wait for concurrent REPACK
+step wakeup_before_lock:
+ SELECT injection_points_wakeup('repack-concurrently-before-lock');
+
+injection_points_wakeup
+-----------------------
+
+(1 row)
+
+step wait_before_lock: <... completed>
+step check1:
+ INSERT INTO relfilenodes(node)
+ SELECT relfilenode FROM pg_class WHERE relname='repack_deadlock';
+
+ SELECT count(DISTINCT node) FROM relfilenodes;
+
+ SELECT i, j FROM repack_deadlock ORDER BY i, j;
+
+ INSERT INTO data_s1(i, j)
+ SELECT i, j FROM repack_deadlock;
+
+ SELECT count(*)
+ FROM data_s1 d1 FULL JOIN data_s2 d2 USING (i, j)
+ WHERE d1.i ISNULL OR d2.i ISNULL;
+
+count
+-----
+ 1
+(1 row)
+
+i|j
+-+-
+1|1
+2|2
+3|3
+4|4
+(4 rows)
+
+count
+-----
+ 4
+(1 row)
+
+injection_points_detach
+-----------------------
+
+(1 row)
+
diff --git a/src/test/modules/injection_points/meson.build b/src/test/modules/injection_points/meson.build
index a414abb924b..1cd88d6db65 100644
--- a/src/test/modules/injection_points/meson.build
+++ b/src/test/modules/injection_points/meson.build
@@ -46,6 +46,7 @@ tests += {
'basic',
'inplace',
'repack',
+ 'repack_deadlock',
'repack_toast',
'syscache-update-pruned',
'heap_lock_update',
diff --git a/src/test/modules/injection_points/specs/repack_deadlock.spec b/src/test/modules/injection_points/specs/repack_deadlock.spec
new file mode 100644
index 00000000000..9d23a6588c2
--- /dev/null
+++ b/src/test/modules/injection_points/specs/repack_deadlock.spec
@@ -0,0 +1,83 @@
+# Test REPACK with a concurrent transaction that would cause a deadlock
+setup
+{
+ CREATE EXTENSION injection_points;
+
+ CREATE TABLE repack_deadlock(i int PRIMARY KEY, j int);
+ INSERT INTO repack_deadlock(i, j) VALUES (1, 1), (2, 2), (3, 3), (4, 4);
+
+ CREATE TABLE relfilenodes(node oid);
+
+ CREATE TABLE data_s1(i int, j int);
+ CREATE TABLE data_s2(i int, j int);
+}
+
+teardown
+{
+ DROP TABLE repack_deadlock;
+ DROP EXTENSION injection_points;
+
+ DROP TABLE relfilenodes;
+ DROP TABLE data_s1;
+ DROP TABLE data_s2;
+}
+
+session s1
+setup
+{
+ SELECT injection_points_set_local();
+ SELECT injection_points_attach('repack-concurrently-before-lock', 'wait');
+}
+# Perform the initial load and wait for s2 to do some data changes.
+step wait_before_lock
+{
+ REPACK (CONCURRENTLY) repack_deadlock USING INDEX repack_deadlock_pkey;
+}
+# Check the table from the perspective of s1.
+#
+# Besides the contents, we also check that relfilenode has changed.
+
+# Have each session write the contents into a table and use FULL JOIN to check
+# if the outputs are identical.
+step check1
+{
+ INSERT INTO relfilenodes(node)
+ SELECT relfilenode FROM pg_class WHERE relname='repack_deadlock';
+
+ SELECT count(DISTINCT node) FROM relfilenodes;
+
+ SELECT i, j FROM repack_deadlock ORDER BY i, j;
+
+ INSERT INTO data_s1(i, j)
+ SELECT i, j FROM repack_deadlock;
+
+ SELECT count(*)
+ FROM data_s1 d1 FULL JOIN data_s2 d2 USING (i, j)
+ WHERE d1.i ISNULL OR d2.i ISNULL;
+}
+teardown
+{
+ SELECT injection_points_detach('repack-concurrently-before-lock');
+}
+
+session s2
+# Change the existing data. UPDATE changes both key and non-key columns. Also
+# update one row twice to test whether tuple version generated by this session
+# can be found.
+step add_column
+{
+ alter table repack_deadlock add column noise text;
+}
+
+step wakeup_before_lock
+{
+ SELECT injection_points_wakeup('repack-concurrently-before-lock');
+}
+
+# Test if data changes introduced while one session is performing REPACK
+# CONCURRENTLY find their way into the table.
+permutation
+ wait_before_lock
+ add_column
+ wakeup_before_lock
+ check1
--
2.47.3
--2fxmamo6mu2qbxgv
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v47-0009-Teach-snapshot-builder-to-skip-transactions-runn.patch"
^ permalink raw reply [nested|flat] 23+ messages in thread
end of thread, other threads:[~2026-03-25 19:35 UTC | newest]
Thread overview: 23+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-05-27 19:06 anoncvs still slow Michael Fuhr <[email protected]>
2006-05-27 20:45 ` Tom Lane <[email protected]>
2006-05-27 21:31 ` Marc G. Fournier <[email protected]>
2006-05-28 19:25 Re: anoncvs still slow Magnus Hagander <[email protected]>
2006-05-28 19:56 ` Devrim GUNDUZ <[email protected]>
2006-05-28 23:42 ` Joshua D. Drake <[email protected]>
2006-05-29 17:14 ` Marc G. Fournier <[email protected]>
2006-05-30 17:52 ` Jim C. Nasby <[email protected]>
2006-05-30 18:01 ` Andrew Dunstan <[email protected]>
2006-05-30 18:12 ` Alvaro Herrera <[email protected]>
2006-05-30 18:16 ` Andrew Dunstan <[email protected]>
2006-05-30 21:16 ` Martijn van Oosterhout <[email protected]>
2006-05-30 19:21 ` Marc G. Fournier <[email protected]>
2006-05-30 23:02 ` Jim C. Nasby <[email protected]>
2006-05-31 00:32 ` Marc G. Fournier <[email protected]>
2006-05-29 17:27 Re: anoncvs still slow Magnus Hagander <[email protected]>
2006-05-29 17:34 ` Marc G. Fournier <[email protected]>
2006-05-29 17:46 Re: anoncvs still slow Magnus Hagander <[email protected]>
2006-05-29 18:00 ` Marc G. Fournier <[email protected]>
2006-05-29 18:21 ` Andrew Sullivan <[email protected]>
2006-05-29 18:20 Re: anoncvs still slow Magnus Hagander <[email protected]>
2006-05-29 18:26 Re: anoncvs still slow Magnus Hagander <[email protected]>
2026-03-25 19:35 [PATCH v47 8/9] Error out any process that would block at REPACK Álvaro Herrera <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox