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.