lpcy commented on issue #5090: URL: https://github.com/apache/couchdb/issues/5090#issuecomment-2172716154
> "Tombstone" is a loose term, more precisely it is a document with the deleted flag set to true, and may contain other data. They are preserved forever, just as non-deleted documents are, to ensure that replication works correctly. You can replicate with a filter to drop them (or any other subset of documents) as long as you're aware of that consequence. > > Delete is not asynchronous (any more than doc create or update is), I'm referring to the way we only wait for the first 2 of the total 3 responses in a 3 or more node cluster, which seems not to apply in your case. > > If this is a single node setup then your opening comment is a bit more interesting. when the DELETE response is returned the document has been marked as deleted, and so any subsequent request should reflect that, including indexes (`_view`, `_find`, etc). Are you querying with stale=ok or update=false parameters? Assuming not, how long is the delay between the deleted document appearing in results after deletion and it finally being gone? Thank you for your patient answer. Actually, what I meant was that the reason for my original question was that I used DELETE in the asynchronous environment of JavaScript, which caused _find to retrieve old data at the same time. This issue can be ignored. The "Tombstone" you mentioned is for replication, but if I don't have replication requirements, is there a simple command to clear them? Will not cleaning them have an impact on database performance? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
