Hi,

we are running a couchdb 1.5.0 setup with master-master replication.

I am observing that sometimes, a document has multiple revisions stored,
and when deleting the most current one, a previous one replaces it
and becomes available.

The old revision numbers that are available are non-consecutives (i.e.
rev 1234 would be replaced by 742). Querying the revs would come back
with a list of non-consecutive revisions, for which a full document
exists even after compactation.

As I understand it, old revision records are kept around for
replication and its contents subject to disappear on compactation. I'd
assume writing a document 1000 times and then issuing a DELETE would
mark it as deleted and inform of this on subsequent GETs.

Has anyone come across anything similar? I have searched around without
much luck.

Is this maybe related to replication conflicts were the conflict is
resolved but the conflicting revisions left behind?

As of now, getting the documents truly deleted means issuing DELETE
a few times until every leftover revision is gone. Of course this only
shows up randomly here and there, and in small tests couchdb deletes
and works as expected.

Thanks,

Hector

Reply via email to