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 > > 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. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
