[
https://issues.apache.org/jira/browse/COUCHDB-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976466#action_12976466
]
Robert Newson commented on COUCHDB-1003:
----------------------------------------
We currently do this, synchronous, on a delete db call;
1) close the file descriptors
2) remove the db from the internal ets tables (lru, etc)
3) rename the file to a different directory and name.
4) A fire-and-forget process is then spawned to delete the file.
On startup, couchdb deletes everything in the .deleted directory.
Spawning a process without waiting for it to complete is perfectly fine if
there's nothing to be gained from waiting, as is the case here.
I don't see what would be achieved by blocking for the deletion like we used to.
> 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.
