-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
underlying *sql.DB not being Closed #97
Comments
You're correct. The Good catch and thanks for reporting the issue! |
This breaks clients that expect to manage the DB lifetime themselves. |
@twalwyn The A DB driver's underlying |
@dhui Given that a common pattern for resource handling is that whoever creates the resource is responsible for cleaning it up, some people might not know that the migrate/driver takes responsibility for instances that are passed in. I think it should be documented somewhere. It also whittles down the usefulness of |
Unfortunately, that's the issue you hit when using @andremarianiello Feel free to open a PR that improves the docs |
Just FYI, I just hit this problem, when I used Of course, using the close method on either migrate or the driver does not only close this connection, but the db too (which, from what I read here, is intended behavior). As @andremarianiello already pointed out, this is neither intuitive nor obvious. As it stands, to work around this issue I have to create one connection to the DB just for migrating, drop that db connection, and then create a second one afterwards for the application to actually use. Is that right? |
@kernle32dll That is what I ended up doing. |
Yeah, it's not intuitive, but docs should help...
Correct, the best approach for now is to use separate db connections for migrate (when using |
I haven’t looked at the code, but can migrate not keep track of whether it opened the db or not, and then only close the db if it created it? |
This is possible but would require tracking extra state in the db instance which would require each db driver implementation to implement this state with the current db driver interface. Going down this path (without a db driver interface change) could result in inconsistencies and additional unexpected behaviors. |
Describe the Bug
While running some tests, I've noticed that even when making sure to
defer migrate.Migrate.Close()
I still run intopq: sorry, too many clients already
I've taken the liberty of digging a little bit and noticed that the
*sql.DB
, after it is used to create thesql.Conn
, it is never closedSteps to Reproduce
Steps to reproduce the behavior:
migrate.Migrate
withmigrate.New(...)
migrate.Migrate.Close()
Expected Behavior
Expect
Close()
to close both thesql.Conn
as well as thesql.DB
Migrate Version
v3.2.0
Loaded Source Drivers
file
Loaded Database Drivers
postgres
Stacktrace
Please provide if available
Additional context
Not sure if theres any reason to not close the
*sql.DB
connection but since it is created from within theOpen
function and never stored, theres no external way to close this db.I'll be fixing it on a personal fork, so if theres no objections to closing the
*sql.DB
connection whenmigrate.Migrate.Close()
is called, I'd be happy to open a PR.The text was updated successfully, but these errors were encountered: