Re: Q: Did you do something to message number recently?

[Eric Wong <e@80x24.org>]

"Eric W. Biederman" <ebiederm@xmission.com> wrote:
> Eric Wong <e@80x24.org> writes:
> 
> > "Eric W. Biederman" <ebiederm@xmission.com> wrote:
> >> The add method computes the number using num_for, which uses
> >> Msgmpa::mid_insert.
> >> 
> >> Short of the sequence number for msgmap getting scrambled I don't
> >> see how that can go wrong.  Sigh.
> >
> > That seems to be what went wrong with "INSERT OR IGNORE"
> >
> > cf. https://public-inbox.org/meta/20190624233809.1721-1-e@80x24.org/
> 
> Is it INSERT OR IGNORE or is it the autoincrement?  As I read
> the sqlite docs autoincrement is allowed to skip message numbers.
> Especially in cases where the insert fails.

Changing it to plain INSERT made the autoincrement stop skipping.
That's been my experience with other DBs in the past, too;
but I haven't used "OR IGNORE" much (and it's been a
long time since I've looked at SQL outside of SQLite).

> This fix should come with a test case shouldn't it?  Such a test
> case should be pretty straight forward to write.  Insert a message
> multiple times and then insert a new one.

Did you see my changes to t/msgmap.t and t/v2writable.t?

I appended the test to existing dupe test in t/msgmap.t and
added the num_highwater check to t/v2writable.t which hit
duplicates.  I don't think there needs to be a separate test,
and the test suite is already slow enough to impact productivity
on my laptop.

> I don't recall the transaction constraints on sqlite but I am wondering
> if instead of INSERT OR IGNORE we should read and the increment
> num_highwater in the public-inbox code and then we would not need to
> depend upon autoincrement only incrementing once.  Even when the sqlite
> docs don't promise it will.

Yeah, that's probably the right step going forward.  I don't
think there's forward/backwards-compatibility things to worry
about, since the indexing code for mirrors already ignores the
autoincrement.