From: ebiederm@xmission.com (Eric W. Biederman)
To: Eric Wong <e@80x24.org>
Cc: meta@public-inbox.org
Subject: Re: Q: Did you do something to message number recently?
Date: Tue, 25 Jun 2019 07:01:54 -0500 [thread overview]
Message-ID: <878stpub4d.fsf@xmission.com> (raw)
In-Reply-To: <20190624234212.j7ghrejyv7ts7y2u@dcvr> (Eric Wong's message of "Mon, 24 Jun 2019 23:42:12 +0000")
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.
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.
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.
>> I will have to instrument my client, and see if that will give
>> me a clue what is going on.
>
> I guess your client ends up seeing the same message
> over-and-over again like -watch does?
It usually doesn't but for dealing with a different imap server I
tweaked the code and one of the servers feeding me the last message in
the mail box every time I checked the mailbox for new messages.
I have also narrowed it down to duplication insertions. I was just
about to start looking at what the fix would be.
>> I think most of my previous work was all in the index rebuild path.
>> Which may be why we don't have a regression test catching this.
>
> Yeah, this isn't a new bug at all. I didn't notice since I
> mainly use w3m or (neo)mutt for NNTP and didn't look too closely
> at NNTP article numbers. lynx makes it apparent messages are
> missing: lynx news.public-inbox.org/inbox.comp.lib.glibc.alpha
It is a little obscure in gnus but I start getting suspcious when
I tell it to give me the last 10 messages and I get only one.
Eric
next prev parent reply other threads:[~2019-06-25 12:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-24 15:59 Q: Did you do something to message number recently? Eric W. Biederman
2019-06-24 16:34 ` Eric Wong
2019-06-24 17:33 ` Eric Wong
2019-06-24 22:56 ` Eric W. Biederman
2019-06-24 23:42 ` Eric Wong
2019-06-25 12:01 ` Eric W. Biederman [this message]
2019-06-25 17:51 ` Eric Wong
2019-06-24 23:38 ` [PATCH] msgmap: mid_insert: use plain "INSERT" to detect duplicates Eric Wong
2019-06-25 3:48 ` Eric Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://public-inbox.org/README
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878stpub4d.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=e@80x24.org \
--cc=meta@public-inbox.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).