driver.ErrBadConn when init packet read fails#736
Merged
arnehormann merged 1 commit intogo-sql-driver:masterfrom Jan 25, 2018
Merged
driver.ErrBadConn when init packet read fails#736arnehormann merged 1 commit intogo-sql-driver:masterfrom
arnehormann merged 1 commit intogo-sql-driver:masterfrom
Conversation
when initializing a connection, we can return drivers.ErrBadConn so that the sql package can use this information to retry getting a connection. the sql package will not give us this behavior unless we return that specific error. pursuant to go-sql-driver#302, this operation is another in the limited set of things that seems safe to retry. we are trying to move to the post-302 world and ran into this :) I've run into this when using the new drivers.Conn() interface specifically, though after digging into the sql package this seems like a similar path for any query. After changing this return, I end up eventually getting a new conn that is valid. It appears in my repro like the db was not yet ready, and would just end up returning an invalid conn and giving up, the InvalidConn err came from https://github.com/go-sql-driver/mysql/blob/4a0c3d73d8579f9fc535cf5e654a651cbd57dd6e/packets.go#L38 which was the first read on the packet (an EOF). At least, returning a drivers.ErrBadConn to let the db retry initializing the connection seems like a safe operation. thanks for maintaining this library :)
3e46420 to
d9709e7
Compare
Contributor
Author
I have a 100% repro here: mattes/migrate#299 -- where before applying this (#736), running |
methane
approved these changes
Jan 13, 2018
Contributor
Author
|
thank you! |
bLamarche413
pushed a commit
to bLamarche413/mysql
that referenced
this pull request
Mar 23, 2018
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
when initializing a connection, we can return drivers.ErrBadConn so that the
sql package can use this information to retry getting a connection. the sql
package will not give us this behavior unless we return that specific error.
pursuant to #302, this operation is another in the limited set of things that
seems safe to retry. we are trying to move to the post-302 world and ran into
this :)
I've run into this when using the new drivers.Conn() interface specifically,
though after digging into the sql package this seems like a similar path for
any query. After changing this return, I end up eventually getting a new conn
that is valid. It appears in my repro like the db was not yet ready, and would
just end up returning an invalid conn and giving up, the InvalidConn err came
from
mysql/packets.go
Line 38 in 4a0c3d7
which was the first read on the packet (an EOF). At least, returning a
drivers.ErrBadConn to let the db retry initializing the connection seems like
a safe operation.
thanks for maintaining this library :)
Description
Please explain the changes you made here.
Checklist