Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
database/sql: ExecContext leaks goroutine on panic. #21248
What version of Go are you using (
@carl-mastrangelo Thank you for the report. I apologize for the delay in getting to this issue.
I'd like to back up a bit. Why do you consider the current behavior a bug? Or more exactly, can you describe how this behavior would be triggered outside of manually adding a panic?
I'm not seeing an error to fix here.
The proposed CL adds another closure which is another allocation and another function call. I would also argue it is slightly more complicated then the original code (although I like the switch statement).
Let me explain my reasoning. The following is common Go code:
Or this example:
Yes, we commonly use defer to ensure resources are closed. However a deeper style/convention is to ensure functions don't panic in the first place. Go makes this easy to check and ensure. Panics don't just "happen". One way the sql package ensures locks are properly used is to use defer when unlocking locks around driver (user package) code. So in principle I agree with you. But defer is cheep and not free. Allocation is cheep, but not free. I have no issue making an allocation when needed, but unlike other languages panics / exceptions are tightly controlled.
On another note, you are not responding to my questions, but just saying "Why? Just merge it already, it is already there and it is better." This is not a productive way forward in any conversation. I've already told you my hesitation. I've now expanded on my hesitation. You are free to refer to someone else to this issue, but I would prefer to first direct your attention and reply to my questions and statements. If we discover they are false or without merit I will happily reverse my decision.
There is no error, just a sharp edge. That is what needs to be fixed.
Moving cleanup code as close to the creation point is good style, in any language.
I think you are intentionally missing the intent of this change. Unless you can statically prove there are no panics possible, why take the chance? Furthermore, it is closer stylistically to the rest of the sql package. Why be a cowboy?
That is the worst possible reason. If you look at my other contributions to the Go project, they have all been performance related. The change as written will not have a measurable impact.
Because you don't see the problem you act on behalf of the whole project. Did you look at the code at all? Even if it didn't match up with anything I said prior, you can see the code is structured better:
I would actually. Who is the next most appropriate reviewer for the