On Wed, Nov 02, 2016 at 11:30:37PM -0400, Richard Hipp wrote: > On 11/2/16, Ben Hearsum <bhear...@mozilla.com> wrote: > > I've also had a couple of kernel panics lately, and I imagine that could > > either directly cause issues, or cause issues the next time Firefox starts > > (and tries to recover). > > SQLite is suppose to recover from a kernel panic without corrupting. > So I hope that is not the cause of your problem. See > https://www.sqlite.org/atomiccommit.html
I strongly suspect Firefox can be blamed, in this case. We occasionly see issues for profiles that are shared between multiple versions of the browesr. I wish I could confirm this, but I'm not able to reliably reproduce the issue. > > > > > With that said, I'm still not clear on one thing: how is it that the *new* > > table and index I've created managed to fail the UNIQUE constraint? Unless > > my SELECTs were lying to me (maybe due to the corruption?), there are no > > duplicate guids in moz_places. > > Yes, the SELECTs are lying to you because of the corruption. Here is > a SELECT that gets you an honest answer: > > SELECT * FROM moz_places WHERE +guid='zK2DS06hrAfO'; > > The "+" in front of "guid" prevents the use of an index and thereby > keeps the answer honest. You'll notice that the above gives you two > rows. But only one of those two rows is in the > moz_places_guid_uniqueindex index and most of the time that index is > used for lookups, thus hiding the second row. Ah, I see! Thank you very much for you time and explanation here. - Ben
signature.asc
Description: PGP signature
_______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
