is HasBGError() strong enough when some error happened in LogAndApply

[lday0321]

we can see that a bg_error_ will be set when db_->blob_file_set_->LogAndApply(edit) return some error at db_impl.cpp:87. and the corresponding has_bg_error_ will be set to true as well to indicate that some bg error happend.

The lightweight flag has_bg_error_ is used to indicate whether some bg error happend and turn the whole db into read only mode and forbid subsequence read/write.

However, in HasBGError() do not hold the mutex_, but return the has_bg_error_ directly. I think there is a chance that some error has been happedn in LogAndApply and bg_error_ has been set to an error code, but has_bg_error_ is still false. In this scenario, the put/write from user is still allowed since HasBGError() return false at this point, then some unpredictable behavior will be happend, such as subsequent version edit will be apply to the manifest file and the manifest info on the disk and the manifest info in the memory (BlobFileSet) is not the same.

Could this be a bug in the titan? HasBGError() should hold the mutex_ as well?

[lance6716]

/label component/titan

[yiwu-arbug]

Indeed we would need to double check HasBGError() while holding mutex_ before every time calling LogAndApply(). Do you mind sending a fix?