History File over 2GB
gja at meowing.net
Fri Aug 30 20:36:26 UTC 2002
bill davidsen wrote:
> Off the top of my head:
> - delete art: cancel, rollover, expire
> delete the pointer, and the article itself in art-per-file
> leaves the msg-id remembered
The rollover stuff might be better noticed and flagged by readers than innd.
> - delete MID from history: expire
> also should delete art?
I can read this as meaning maybe three different things. MAybe an example?
> - checkhistory: incoming arts
> just return seen/unseen (wwould this be faster than graphistory?)
Definitely faster if you're only checking a small number of IDs per
process. dbz can already do this, it just needs to be exposed, really.
> - grephistory: head, article, feed
> MID->SM_token (or fail)
sm and grephistory could stand some small tweaks. What I'd like to see:
- grephistory gets an "interactive" mode kind of like what sm with no
command flags now.
- sm's interactive mode prepends an rnews header (easy) or spits out a
dot-stuffed-and-termed article (busier and probably less useful) to make
it more suitable for running through a pipe.
I kind of like that the two aren't currently trying to do each other's
job, though. Any more elaborate, and you might as well just fire up an
> and it would probably be better to include a flag to delete overview for
> an article as well, to avoid mismatches between data and information.
> Clearly this would be a problem for non-database overview, perhaps a
> queue of deletes to process? Not easy to do fast, but expire is
> something I'd love to avoid.
tradinidexed in particular wants careful handling, since that and
tradspool are supposed to be there to support spool-based readers. The
cheap and easy approach of poking an invalidation string into the middle
of .overview kind of loses there =(
None at this time, um, never mind.
More information about the inn-workers