On Wed, Sep 2, 2020 at 3:16 PM Ranier Vilela <ranier...@gmail.com> wrote: > Oh, I'm sorry, I thought that "hard crash" was a bad thing.
I think that you are being sarcastic here, but just in case I'm wrong I'll clarify what I meant: a good sign that a static analysis tool has produced a useless complaint is that it appears to prove something far stronger than you first thought possible. You should look out for that. This is just a heuristic, but in practice it is a good one. Perhaps you recall our discussion of a similar false positive in nbtsplitloc.c; that had a similar feel to it. For example, if your static analysis tool says that code that has been around for many years is riddled with bugs, then the problem is almost certainly with the tool (or with how the tool has been used). High performance C code very often relies on representational invariants that may not be readily apparent to a compiler -- especially when dealing with on-disk state. Barring some obvious problem like a hard crash, you have to do the work of assessing if the code is correct based on the actual assumptions/context of the code. A static analysis tool is of very little use if you're not going to put the work in. I went to a lot of trouble to clearly document the code in question here (the heap TID stuff in _bt_truncate()) -- did you even bother to read those comments once? -- Peter Geoghegan
