You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2019/04/11 18:23:29 UTC

[GitHub] [couchdb] chewbranca commented on issue #2003: Don't reset_index if read_header fails

chewbranca commented on issue #2003: Don't reset_index if read_header fails
URL: https://github.com/apache/couchdb/pull/2003#issuecomment-482241405
 
 
   > @rnewson which process would crash and why that would cause read_header() to throw?
   
   I suspect there are multiple ways in which this could happen through the code path, but one highly plausible scenario is when the `couch_file:read_header` call is made, that request goes through an IOQ pid [1], and if that IOQ pid exits, we'll get a `gen_server:call` error that falls into the `_` codepath here and triggers an index reset. When that happens, the `couch_file:truncate` call (along with sync) go directly to the Fd pid and skip going through IOQ [2]. So a read_header requests sitting in IOQ that then exits could trigger a faulty index reset.
   
   One approach is we could look for `gen_server:call` errors and skip resetting in those scenarios, but I think we would be better off explicitly resetting _only_ when we get the `no_valid_header` error. Also, the `couch_mrview_util:reset_index` call both truncates the index and writes a new base header [3], so it's quite possible that this code path is used to initialize empty indexes, and as such, I think we should keep the reset_index logic in here unless we can verify that indexes are bootstrapped always elsewhere and that this logic isn't needed.
   
   
   [1] https://github.com/apache/couchdb/blob/17aec1f3339f864eb08869d6235753f0fdd28259/src/couch/src/couch_file.erl#L326-L332
   [2] https://github.com/apache/couchdb/blob/17aec1f3339f864eb08869d6235753f0fdd28259/src/couch/src/couch_file.erl#L206-L223
   [3] https://github.com/apache/couchdb/blob/17aec1f3339f864eb08869d6235753f0fdd28259/src/couch_mrview/src/couch_mrview_util.erl#L679

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services