If #2 is all it takes to fix the trace, and if there are no negative effects, then that's what I vote for.
I agree. Fixing the trace is important, sending the right database name in the PKGNAMCSN is important, and solution #2 gets my vote as well.
I think it was important to explore the issue to this level of detail, to satisfy ourselves that there were no other functional problems besides the trace (that is, that we didn't execute the wrong queries, or mix up the results from two queries issued at the same time, or something like that). Also, I was hoping that we would be able to construct a regression test for this change, as something other than: - run this test program with these trace flags set - read the trace files and make sure they look ok as I would have preferred to see a more automatic regression test of some sort. But I haven't thought of a simple way to write such a regression test. Julius, I think that it's still worth incorporating your test program(s) into the patch as you construct it, even though using those test programs requires some manual actions (enabling the trace flags, reading the trace files). I think it would be good to include the instructions for how to use the test program(s) to verify the correct operation of the patch as code comments in the test programs themselves. This will be useful at least during the review of the patch, but I think that there's no harm in including the test programs as a permanent part of the regression suite, as they exercise a certain path through the code and shouldn't cause too much of a performance impact. And thanks for the detailed analysis of the problem, Julius; it has been quite illuminating to read your notes. thanks, bryan
