New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
database/sql/driver: ErrBadConn hides underlying error message #20807
Comments
@captncraig Thanks for filing this here. The other alternative is to return the original error while marking the connection internally as a bad connection. Then when it is requested again, from the pool the driver.ErrBadConn is returned. I would however prefer to avoid that. It prevents the connection pool from making intelligent decisions and introduces latency on the hot query path. If we did this, I would be okay with either solution. I'd probably go with the one that could be implemented more efficiently at runtime (which test is more efficient). Though all else equal I'd lean towards the IsBadConn interface. |
I guess yet another alternative would be something on the context that the driver can interact with to signal a connection is bad. So driver could do something like:
I kinda like that as well, but it has some odd complexity. And I have no idea what to call it. |
Change https://golang.org/cl/67630 mentions this issue: |
Change https://golang.org/cl/73033 mentions this issue: |
A single database connection ususally maps to a single session. A connection pool is logically also a session pool. Most sessions have a way to reset the session state which is desirable to prevent one bad query from poisoning another later query with temp table name conflicts or other persistent session resources. It also lets drivers provide users with better error messages from queryies when the underlying transport or query method fails. Internally the driver connection should now be marked as bad, but return the actual connection. When ResetSession is called on the connection it should return driver.ErrBadConn to remove it from the connection pool. Previously drivers had to choose between meaningful error messages or poisoning the connection pool. Lastly update TestPoolExhaustOnCancel from relying on a WAIT query fixing a flaky timeout issue exposed by this change. Fixes #22049 Fixes #20807 Change-Id: I2b5df6d954a38d0ad93bf1922ec16e74c827274c Reviewed-on: https://go-review.googlesource.com/73033 Run-TryBot: Daniel Theophanes <kardianos@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go 1.8.3
What did you do?
database/sql/driver
definesErrBadConn
that a driver should return if a connection is rendered unusable. The mssql driver recently merged a pr to use this in more instances. It corrected a few intermittent issues I was having with bad connection reuse, it now gives error messages that are almost completely unhelpful.Where I used to have things like "IO timeout" returned to the user code, I now only get "driver: bad connection". This seems unavoidable at present because
ErrBadConn
is defined simply as:var ErrBadConn = errors.New("driver: bad connection")
Ideally, the driver would be able to return any error message it likes, while still being able to signal to the database/sql package to not reuse this connections.
I have a couple of ideas for this perhaps:
interface{ IsBadConn() bool}
or something. Could be exported or unexported.driver
package. Maybe something liketype BadConnError struct{ error }
. Or perhaps an unexported type with afunc WrapAsBadConn(err error) error
to create them.In either case, the usages of
err == driver.ErrBadConn
would likely be replaced with a call todriver.IsBadConn(err)
or similar, which would perform the additional type checks.Does this make any sense? Would you be likely to consider a change to this effect for go 1.10?
I don't envision it being a largely impactful change, except perhaps if someone outside the std lib is ever checking errors for equality with
driver.ErrBadConn
. It is a possibility I suppose.The text was updated successfully, but these errors were encountered: