I wrote the second of these patches first, and I'm uncertain about the desirability of the first of the patches.
While working on the uninstrumented code path bulk patch, I noticed that nested transactions within the copy of the outermost transaction were not being processed for an uninstrumented code path, and so were only receiving an instrumented path. This is clearly less than ideal when considering HTM. Now, it seemed to me that if we're already in an uninstrumented code path, we're extremely likely to want to stay in one. This is certainly true for HTM, as well as when we've selected the serialirr method. I can't think off hand of any other reason we'd be on the uninstrumented code path. Therefore the second patch arranges for all nested transactions in the uninstrumented path to _only_ have uninstrumented paths themselves. While reviewing the results of this second patch in detail, I noticed that nested transactions on the instrumented code paths were not generating both instrumented and uninstrumented code paths. My first reaction was that this was a bug, and so I wrote the first patch to fix it. But as I was reviewing the patch to write the changelog, I began to wonder whether the same logic concerning the original instrumented/ uninstrumented choice applies as well to the instrumented path. Is it ever likely that we'd choose an uninstrumented path for a nested transaction, given that we're already executing the instrumented path for an outer transaction? It now seems to me that the only time we'd switch from instrumented to uninstrumented code path would be during a transaction restart, after having selected to retry with a serialirr method. Which means that I should apply the second patch only, Thoughts? r~
