His report is attached, but the gist of it is that articles containing
Supersedes: headers --- as most FAQs do --- may get dropped at sites
that are running INND with a particular patch. If news.answers seems to
have a considerable shortage of articles at your local news server, this
bug may be the cause.
I thought I'd forward this info to faq-maintainers so that people would
know what was up, and so they could pester their local newsadmins
to install the fix if necessary.
regards, tom lane
------- Forwarded Message
Date: Wed, 29 Oct 1997 11:37:09 -0600 (CST)
From: nc0548@freebsd.netcom.com (Mark Hittinger)
To: tgl@netcom.com
Subject: Supersedes: header problem
Tom you may go ahead and release what I've told you, thank you for hanging
on to it for a bit. I have contacted the original author of the patch
which has caused this problem and he will be issuing a correction to the
innd developers list.
The patch in question is the "early cancel optimization" patch submitted
by Sang-yong Suh (sysuh@news.kigam.re.kr).
During today's normal news server operation a site will receive a very
significant number of cancel control messages for spam. If the cancel
arrives before the spam arrives, this is called an "early cancel". If
the cancel arrives after the spam arrives, this is called a "late cancel".
For sites which have dedicated back end feeds or for sites which use
a master/slave configration, it is possible to have the master node
process the early cancel and not propogate it to the subsidiary machines.
For our site it is roughly 15% of the newsfeed bandwidth, although for
a foreign site (such as .kr) it may be as high as 35%.
This improves performance and reduces the size of the history files on
the subsidiary machines. All good.
Unfortunately there is a special case of the Supersedes: header and Sang-yong's
patch incorrectly identifies articles containing Supersedes: headers as
early cancels.
Netcom's outgoing feeds are not configured to suppress early cancels going
out so your JPG FAQ articles were propogated to our usenet peers. They
were not propogated internally because the internal feeds are configured
to suppress propogation of early cancels.
We've applied and tested the following patch and it appears to resolve the
problem. This change is needed ONLY on sites which are using Sang-yong's
early cancel patch!
Regards,
Mark Hittinger
Netcom/Dallas
nc0548@freebsd.netcom.com
*** art.c.orig Tue Oct 28 17:36:39 1997
--- art.c Tue Oct 28 20:55:32 1997
***************
*** 2186,2207 ****
* seem to be worth it. */
Data.IsEarlyCancel = FALSE;
if (Accepted) {
p = HDR(_supersedes);
if (*p && ARTidok(p))
{
TMRstart(TMR_ARTCNCL) ;
ARTcancel(&Data, p, FALSE);
TMRstop(TMR_ARTCNCL) ;
}
if (ControlHeader >= 0) {
- Data.IsEarlyCancel = FALSE;
TMRstart(TMR_ARTCTRL) ;
ARTcontrol(&Data, HDR(ControlHeader));
TMRstop(TMR_ARTCTRL) ;
}
}
/* Start logging, then propagate the article. */
ARTlog(&Data, Accepted ? ART_ACCEPT : ART_JUNK, (char *)NULL);
#if defined(DO_NNTPLINK_LOG)
if (fprintf(Log, " (%s)", Data.Name) == EOF || ferror(Log)) {
IOError("logging nntplink");
--- 2186,2207 ----
* seem to be worth it. */
Data.IsEarlyCancel = FALSE;
if (Accepted) {
p = HDR(_supersedes);
if (*p && ARTidok(p))
{
TMRstart(TMR_ARTCNCL) ;
ARTcancel(&Data, p, FALSE);
TMRstop(TMR_ARTCNCL) ;
}
+ Data.IsEarlyCancel = FALSE;
if (ControlHeader >= 0) {
TMRstart(TMR_ARTCTRL) ;
ARTcontrol(&Data, HDR(ControlHeader));
TMRstop(TMR_ARTCTRL) ;
}
}
/* Start logging, then propagate the article. */
ARTlog(&Data, Accepted ? ART_ACCEPT : ART_JUNK, (char *)NULL);
#if defined(DO_NNTPLINK_LOG)
if (fprintf(Log, " (%s)", Data.Name) == EOF || ferror(Log)) {
IOError("logging nntplink");
------- End of Forwarded Message