[ https://issues.apache.org/jira/browse/COUCHDB-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851924#action_12851924 ] Dirkjan Ochtman commented on COUCHDB-721: ----------------------------------------- Thanks, I was going to file myself this morning, but then you already had. I chatted with Damien about this last night, here's what we came up with: 20:21 okay, the database looks completely correct on my side. must be something wirth you view indexes then. 20:26 the page-22 document doesn't exist in my pages/list view 20:26 it does in mine 20:27 right, it's sounds like it's the index that's wrong. 20:27 but the return for conflicts=true is the same 20:27 I'm confused, shouldn't revs_info also show the conflicts? 20:29 djc: no, it only shows the revs for that edit "branch": 20:29 each conflict is a different edit branch, that's what makes them conflicts. 20:29 so revs_info shows all the previous edits to that particular document rev. 20:30 okay... 20:31 still, that would indicate that I have overwritten page-22 at some point with an empty doc? 20:31 yes 20:32 djc: the conflicts still have data 20:33 err, no they don't 20:33 has content: http://127.0.0.1:5984/vjk/page-22?rev=2-1835830930 20:34 yeah, and that's the one that shows up in my view 20:36 gtg, bbiab 20:44 djc: save your view index file for me to download. To fix the inconsistency between the view and the db, delete the index file for it to be rebuilt. 20:48 right, but then I have to make sure I merge all the conflicts 20:48 I don't even know how to do that, I think, but I bet there's a wiki page 20:48 djc: delete the other revs 20:49 DELETE db/doc?rev=4-4212453249 20:50 ok 20:58 djc: also, can you write up a bug report for this? 20:58 just for the view indexer, right? 20:58 Right. The bug seems to be that the view index got out of sync with the databse file. 20:59 http://dirkjan.ochtman.nl/couch-issue/views.tar.gz 20:59 it's still weird how that empty revision got there 21:00 djc: there might still be another bug in couchdb there. or it might the out of sync index caused a problem in the app logic? 21:02 the app doesn't write to these documents 21:02 I've only done that by hand (albeit through a script) 21:02 we can't trace a seq to a timestamp, right? 21:02 I guess maybe I could trawl through the logs 21:03 but even then it would be in a bulk update > possible data corruption after upgrade & compaction > --------------------------------------------------- > > Key: COUCHDB-721 > URL: https://issues.apache.org/jira/browse/COUCHDB-721 > Project: CouchDB > Issue Type: Bug > Components: Database Core > Affects Versions: 0.11 > Reporter: Timothy Smith > > Problem report filed on behalf of dev@couchdb.apache.org e-mail, subject "Compaction issue after upgrade 0.10.1-0.11.0". > So this morning I went to upgrade one of my servers to 0.11. Installed > it, fixed up the config files, then restarted CouchDB. It picked up on > my databases just fine, so everything looked good. I tried some views, > and it had to re-index all of my ddocs (which I found surprising, but > okay). After that I went and compacted the database, then the views. > However, later today I got some exception mails from my web > application. It appears that something has gotten confused. For > example, take this document: > {_id: "page-22", _rev: "2-1835830930", lb: null, content: "blah blah > yadda", type: "page", _deleted_conflicts: ["4-4212453249", > "2-1982019940", "2-1964049796", "2-1096626370"]} > Note all the _deleted_conflicts. However, this is the document > returned by a view (which emits(doc.lb, doc))! When I actually request > this document, I get this: > {"_id":"page-22","_rev":"4-4212453249"} (it would be helpful to have a > member _deleted:true, or something, to show that it's not just empty, > but that something was there before). > Requesting the 2-1835830930 revision results in the complete document, > as shown above. > So, that got me pretty scared, because I thought I lost my document > (and my site actually started failing)! What would be the best way to > fix up my database? And do we have any diagnosis on what the cause of > this is? I'm happy I deployed this on a less-critical site first, and > wouldn't want to deploy at work unless we figure out what's going on > here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.