couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: possible compact bug in 1.1.1
Date Tue, 22 Nov 2011 19:54:01 GMT
On Tue, Nov 22, 2011 at 4:43 AM, Szabo, Viktor (Enterprise
Infrastructure) <> wrote:
> Hi CouchDB users,
> I don't know if this is a known issue or not, but I've been experiencing strange behaviour
in version 1.1.1
> after initiating compaction. Even though there's already a doc with the _id value of
"dummy" in my database,
> if I want to have it re-inserted after a compact operation is started, 9 times out of
10, I receive an "ok":true
> notification. Occasionally I'm seeing the expected conflict error.
> $ curl -X POST -H "Content-type: application/json" http://hostname:7002/test/_compact
> {"ok":true}
> $ curl -X POST -H "Content-type: application/json" -H "Referer: http://hostname:7002/"
http://hostname:7002/test -d '{ "_id": "dummy" }'
> {"ok":true,"id":"dummy","rev":"1-967a00dff5e02add41819138abb3284d"}
> $ curl -X POST -H "Content-type: application/json" http://hostname:7002/test/_compact
> {"ok":true}
> $ curl -X POST -H "Content-type: application/json" -H "Referer: http://hostname:7002/"
http://hostname:7002/test -d '{ "_id": "dummy" }'
> {"ok":true,"id":"dummy","rev":"1-967a00dff5e02add41819138abb3284d"}
> How is this possible?
> Given that I sometimes get an "ok" confirmation, but sometimes get a "conflict error"
for the very same request sent to the
> database with the very same content, I don't really feel secure about the integrity of
the service.
> I'm thinking that the issue is related to the fact that the database already had accepted
a doc with the same id and content,
> but still, undeterministic behaviour is not something I like.
> Do you have a clue on what might be going on?
> (I wasn't able to reproduce under 1.1.0. Used a single-node instance with no replication
set up and no clients connecting to the service)
> Thanks,
> Viktor
> --------------------------------------------------------------------------
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views
contained herein are not intended to be, and do not constitute, advice within the meaning
of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have
received this communication in error, please destroy all electronic and paper copies and notify
the sender immediately. Mistransmission is not intended to waive confidentiality or privilege.
Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor
electronic communications. This message is subject to terms available at the following link: If you cannot access these links, please notify
us by reply message and we will send the contents to you. By messaging with Morgan Stanley
you consent to the foregoing.

Your example here is actually hitting a very specific edge case as
demonstrated by Marcello's test. As of many versions ago, revisions
are generated using a hashing scheme of the document contents. In your
particular case the requests you're issuing contain the same identical
data in such a way that CouchDB will generate a revision of the doc.

Given this, we then have to look at how this plays into replication.
Basically, when we merge the revision trees we get to the case where
it's "oh, we already have this version, cool" because we do already
have this version.

Whether or not that behavior is best, or if we should force a conflict
if we don't add a leaf during a write is another question. In other
words, the system is working fine, but this particular behavior can be
a bit unexpected.

View raw message