Responding to myself:

> FWIW, one of the case that can trigger the "can't store article" in
> innd is when INT_MAX is reached.
I do not manage to reproduce it on my current VPS...
A few years ago, with an older hardware and OS, I had "436 can't store
article".

Now, on my set up, INN is happily accepting articles > 2^31. No storage
error, and article numbers > 2^31 are present in NNTP responses.

LIST ACTIVE returns large article numbers for all the storage methods:

trigofacile.test.maxartnum.cnfs 2147483649 2147483646 y
trigofacile.test.maxartnum.timecaf 2147483648 2147483646 y
trigofacile.test.maxartnum.timehash 2147483651 2147483646 y
trigofacile.test.maxartnum.trash 2147483648 2147483646 y
trigofacile.test.maxartnum.tradspool 2147483650 2147483646 y

Articles are stored in disk, and accessible via ARTICLE <mid> requests
(not by article numbers though).

The overall behaviour depends on the overview method used.

With tradindexed, article numbers > 2^31 are not returned in LISTGROUP,
OVER and like commands because they are not present in the index
("cannot write index record for 18446744071562067968" - seems like
article number wraps to -1 and then is written 2^64 as unsigned long in
the log).

buffindexed returns the articles but not with the right numbers:

LISTGROUP
211 3 2147483646 18446744071562067969 trigofacile.test.maxartnum.timehash
2147483647
2147483648
18446744071562067969
..

though the last one correctly has:

Xref: news.trigofacile.com trigofacile.test.maxartnum.timehash:2147483649

ovdb returns the right article numbers except for the reported high
water mark:

LISTGROUP
211 3 2147483646 18446744071562067969 trigofacile.test.maxartnum.timehash
2147483647
2147483648
2147483649
..

but OVER responses report negative article numbers starting from -2^31:
-2147483648, -2147483647, etc.

ovsqlite has a different and strange behaviour as the low and high water
marks are inverted, and article numbers are also returned in reverse order:

LISTGROUP
211 4 18446744071562067968 2147483647 trigofacile.test.maxartnum.timehash
18446744071562067968
18446744071562067969
18446744071562067970
2147483647
..

It was just a quick testing of overview methods. (Expiry and other
programs not tested.)
So there's a bit of work and testing afterwards to make INN compatible
with 2^64 article numbers. At least the good news is that the storage
methods cope with a bit more than 2^31 (maybe 2^32 and beyond) but there
will be a problem with numbers > 10^10 because of the format of the
active file.

For the time being, I'll have a look to prevent postings of new articles
in newsgroups which have reached 2^31-1 articles, with the correct
rejection code (and not deferral).
It will fix the "can't store article" error I once had (which certainly
still happens for some people), and otherwise these wrong article
numbers returned if the article is accepted.

--
Julien ÉLIE

« On appelle ça une insula. C'est une maison où les gens habitent les
uns au-dessus des autres… » (Astérix)