[
https://issues.apache.org/jira/browse/COUCHDB-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976495#action_12976495
]
Benoit Chesneau commented on COUCHDB-1003:
------------------------------------------
Thanks for the link to 780 issue, I couldn't find it. So, the decision was to
let a note for .delete files and let them around if something happen. I don't
like it so much. But except that, while async delete is enough good for
compaction (and needed right now) I don't see why we use it for removing a db.
To be clear, we are sending a status 200 in response to a db DELETE while we
aren't sure the db was deleted. rename != delete. data could still be on the
disk or data could simply be not deleted for any reason. Relying on an external
script or restart of couchdb to handle final delete isn't so good, this is
another thing to monitor and check. In my opinion, until we don't wait for a
full delete (which could be needed in a scenario where dbs are crypted) it
could be interesting to:
- send a 202 status instead of 200
- have a task that collect deletions and eventually log and clean them if
needed.
- what do you think ?
> deleting db file is asynchronous & file rename in couch_file:delete
> -------------------------------------------------------------------
>
> Key: COUCHDB-1003
> URL: https://issues.apache.org/jira/browse/COUCHDB-1003
> Project: CouchDB
> Issue Type: Question
> Components: Database Core
> Reporter: Benoit Chesneau
>
> I wonder why we spawn the file deletion when we delete a database. On slow io
> machine it introduces latency. I don't see any reason we make this deletion
> asynchronous ?
> About couch_file:delete, we first rename the file before deleting it. Why are
> we doing that ? Is this for windows ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
