Qian Wang
unread,Jun 17, 2024, 3:59:51 AMJun 17Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to rocksdb
In RocksDB, if a non-OK Status is obtained in the innermost code, it is generally propagated up to the outermost layers, where a top-level logic might call SetBgErr() to set a global bg_err_. When other threads receive this bg_err_, they set their current Status to bg_err_ and then return it to the external interface caller of RocksDB.
This architecture leads to a problem: I get a non-OK Status in the LOG, but there is no way to know what the call stack looked like when it was generated. Do you have any good suggestions to help me get more information when I get a non-OK Status?
One method I can think of is to add the name of the current function to the Status as it is passed outward, in order to record a call stack.But I don't know how to implement the above method in RocksDB with minimal intrusion into the original code.