Skip to content
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

Closed
captncraig opened this issue Jun 27, 2017 · 4 comments
Closed

database/sql/driver: ErrBadConn hides underlying error message #20807

captncraig opened this issue Jun 27, 2017 · 4 comments
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@captncraig
Copy link

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 defines ErrBadConn 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:

  1. Allow drivers to return an error that implements some other interface. Perhaps interface{ IsBadConn() bool} or something. Could be exported or unexported.
  2. Have a wrapper type available in the driver package. Maybe something like type BadConnError struct{ error }. Or perhaps an unexported type with a func WrapAsBadConn(err error) error to create them.

In either case, the usages of err == driver.ErrBadConn would likely be replaced with a call to driver.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.

@bradfitz bradfitz added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jun 27, 2017
@bradfitz bradfitz added this to the Go1.10 milestone Jun 27, 2017
@kardianos
Copy link
Contributor

@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.

@captncraig
Copy link
Author

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:

if err != nil{
   // instead of 
   // return driver.ErrBadConn
   driver.GetBadConnThing(ctx).MarkBad()
   return err
}

I kinda like that as well, but it has some odd complexity. And I have no idea what to call it.

@gopherbot
Copy link

Change https://golang.org/cl/67630 mentions this issue: database/sql: add driver.ResetSessioner and add pool support

@gopherbot
Copy link

Change https://golang.org/cl/73033 mentions this issue: database/sql: add driver.ResetSessioner and add pool support

gopherbot pushed a commit that referenced this issue Oct 24, 2017
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>
@golang golang locked and limited conversation to collaborators Oct 24, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

4 participants