Error in makehistory man page
Richard Todd
rmtodd at servalan.servalan.com
Sun Apr 30 21:26:20 UTC 2000
In message <20000430180722F.kondou at inn.do.mms.mt.nec.co.jp>, Katsuhiro Kondou w
rites:
>In article <ylzoqcxwg5.fsf at windlord.stanford.edu>,
> Russ Allbery <rra at stanford.edu> wrote;
>
>} By "done internally," you mean to have makehistory always have the -u
>} behavior if there's an existing history file and have people remove the
>} existing history file if they really want a complete rebuild? Or do you
>} mean something else?
>
>Ouch, I should have looked into the code more carefully.
>That was my over thought. Sorry for confusing. But I'd
>say -u should not be used for buffindexed, since it just
>appends index/data and this means occupied buffer will
>grow to over double size until next expireover. As to
>tradindexed, data (not index) is also appended and the
>same problem occurs.
No, -u only adds articles if it finds them missing in the existing history
database, so this would only happen if the majority of the articles in spool
aren't in the databases. Arguably if the existing databases are that far
out of whack, you're probably better off shutting down innd and rebuilding
them all from scratch.
Also, this isn't really specific to -u; rebuilding the entire overview with
makehistory -O -x causes the same situation. It's still an extrordinarily
useful thing to be able to do while the server's up, if you've got the disk
space to do it. Perhaps we should note in the documentation that these
techniques to try to rebuild the overview db while the server is up, they'd
better have enough free space, and if they don't, they'll have to shut down
and wipe out the existing overview before rebuilding. For 2.4 we should
perhaps look and see if there's some way to get makehistory to automatically
compact the tradindexed/buffindexed databases when needed.
More information about the inn-workers
mailing list