[
https://issues.apache.org/jira/browse/COUCHDB-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976500#action_12976500
]
Filipe Manana commented on COUCHDB-1003:
----------------------------------------
"Note:
this isn't the only test where we do apply such fix. Feel free to reopen the
ticket anyway. "
Benoît, what other tests do that? The only ones that do a wait loop I can
remember, like replicator_db.js, do it to wait for something to happen and not
to fix an issue like this one.
And as for the 2nd file descriptor, it's ref counted like the updater file
descriptor. I don't it's the cause for this.
> 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.
