Yea, I going to have to back track, I didn’t read deep enough on the test to see that it was polling and waiting.
At the same time, I am not sure how this would would if the driver isn’t signaling to all open connections that you should close… and then coordinating it. Like a lot in the Go stdlib it seems underspecified. I am going to agree with you that the documentation is incorrect. Maybe there is a path to a FullyCloseWithTimeout to be added to the stdlib which doesn’t essentially what the test case does. BUT, I still don’t see where in the api what closing the db means to a connection that I already have that I am making calls on. How will I even know that the database is closing and I should close my connection and /or do an orderly shutdown? That’s why it seems underspecified. I think this is why there is no “DB” concept in Java. You just have a connection to a database (which may be pooled/cached behind the scenes). If the db goes down, you won’t know until you try and use the connection - and its up to you to coordinate outside lifecycle activities. > On Nov 11, 2025, at 1:43 AM, Toby Allsopp <[email protected]> wrote: > > Hi, thanks for your response. My reply is inline below. > > On Saturday, 8 November 2025 at 10:18:12 UTC+13 robert engels wrote: > I looked through the code some more, and I think these lines are where the > connector should close/wait for outstanding connections to be finished. > > https://github.com/golang/go/blob/d36e88f21f56dcf45fed2231fe28f948a31c936b/src/database/sql/sql.go#L951C1-L956C3 > > I would assume this is the connector’s responsibility as long as it > implements io.Closer. > > I have’t run anything through we I could break point and see what’s going on. > > I look through the other structures and it certainly seems like closing and > waiting (for statements on each connection to be done) is a responsibility. > > I agree that the connector _could_ keep track of connections and then block > waiting for them to be closed in its Close method, and that this would cause > the DB.Close method to block and wait for all the connections to be returned > to the pool and thus be closed. > > But, I can't find a single example of a connector that actually does that. > > In the standard library, we have database/sql.dsnConnector, which is used for > drivers that don't implement DriverContext. This doesn't have a Close method. > > The very popular pgx library also doesn't have a Close method on its > connector type: > https://github.com/jackc/pgx/blob/f2d5d4447821540092446e81246c0d9c27acf5cf/stdlib/sql.go#L256 > > No Close method in the github.com/go-sql-driver/mysql > <http://github.com/go-sql-driver/mysql> driver either: > https://github.com/go-sql-driver/mysql/blob/76c00e35a8d48f8f70f0e7dffe584692bd3fa612/connector.go#L21 > > I think it's more likely that the documentation for DB.Close is misleading, > and it is _not_ expected to block waiting for all connections to be closed, > than every implementation of driver.Connector, including in the standard > library, is missing an undocumented requirement to track and wait for > connection in their optional Close method. > > Or have I misunderstood your point? > > Cheers, > Toby. > > > But the stblib test case would fail if there were open connections are the > close, based on these: > > https://github.com/golang/go/blob/5cd1b73772e339e3b460d53ba37630704a323ca7/src/database/sql/sql_test.go#L176C2-L182C3 > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/b09ff43a-0713-4b88-bbc4-374c63f1f828n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/b09ff43a-0713-4b88-bbc4-374c63f1f828n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/4564C976-3248-4850-A3BF-C879C5C3DA0D%40ix.netcom.com.
