2010/2/1 Matteo Beccati <p...@beccati.com>: > On 01/02/2010 15:03, Magnus Hagander wrote: >> >> 2010/2/1 Matteo Beccati<p...@beccati.com>: >>> >>> My main concern is that we'd need to overcomplicate the thread detection >>> algorithm so that it better deals with delayed messages: as it currently >>> works, the replies to a missing message get linked to the "grand-parent". >>> Injecting the missing message afterwards will put it at the same level as >>> its replies. If it happens only once in a while I guess we can live with >>> it, but definitely not if it happens tens of times a day. >> >> That can potentially be a problem. >> >> Consider the case where message A it sent. Mesasge B is a response to >> A, and message C is a response to B. Now assume B is held for >> moderation (because the poser is not on the list, or because it trips >> some other thing), then message C will definitely arrive before >> message B. Is that going to cause problems with this method? >> >> Another case where the same thing will happen is if message delivery >> of B gets for example graylisted, or is just slow from sender B, but >> gets quickly delivered to the author of message A (because of a direct >> CC). In this case, the author of message A may respond to it (making >> message D),and this will again arrive before message B because author >> A is not graylisted. >> >> So the system definitely needs to deal with out-of-order delivery. > > Hmm, it looks like I didn't factor in direct CCs when thinking about > potential problems with the simplified algorithm. Thanks for raising that.
That is a very common scenario. And even without that, email taking different time to get delivered to majordomo is not at all uncomoon. > I'll be out of town for a few days, but I will see what I can do when I get > back. No rush. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
