See this code and similar logic in col_search.c. Since it isn't doing an atomic maximum, it is possible for one thread to set it to a higher value between the check and the store, and for the value to then be set lower.

It looks like this is currently only used for stats tracking, and should self-correcting on the next search to this tree, this is probably a benign race right now. However, since depth increases are rare events (unless something goes terribly wrong with balancing, it probably never happens more than 30 times per tree), there isn't much reason to not just do the cas loop or use arm's atomic ldumax instruction. That avoids the risk that we start using the depth for something important.

Alternatively, we should consider storing the depth in the root node (or its pointer). It should only increase when the root splits, which requires an update there anyway, and that would make it always correct without needing to update it on reads.