couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Chesneau (JIRA)" <>
Subject [jira] Commented: (COUCHDB-1003) deleting db file is asynchronous & file rename in couch_file:delete
Date Sun, 02 Jan 2011 09:24:45 GMT


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:
>             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.

View raw message