Isn’t the design supposed to be that the driver maintains the connections so when you close the db, it closes the driver connection, and that should wait until the current statements complete or terminate them. Terminating a live connection is going to be db specific.

I think it is driver issue. 

On Nov 5, 2025, at 10:31 PM, 'Sean Liao' via golang-nuts <[email protected]> wrote:


I agree then that the docs don't match the current behavior, open an issue. 
Less clear to me is whether the fix is to change the docs or change the behavior to match the current docs. 
But the current design certainly doesn't hold references to conns that have been handed out.

- sean

On Thu, Nov 6, 2025, 03:15 Toby Allsopp <[email protected]> wrote:
Hi! Response inline below.

On Thursday, 6 November 2025 at 13:46:18 UTC+13 Sean Liao wrote:
Why do you think it doesn't wait for all connections to be closed and freed?

I have three pieces of evidence:

1. Experimentally, in our application, we observe that connections are still open when DB.Close returns.

We're using SQLite, and sometimes we want to replace the SQLite database file with a new version received from another machine. In order to do this, we require that there are no connections open to the database. On Windows, we experienced errors when replacing the sqlite database file after calling DB.Close. When we added a polling loop waiting for the number of in-use connections (using DB.DBStats) to go to zero after calling DB.Close, the errors stopped happening.

2. Inspecting the source for the Close method, there is code that deals with idle connections and connection requests, but nothing about in-use connections.


3. The unit tests for the database/sql package use a helper function to wait for connections to be closed after DB.Close is called.


Thanks,
Toby.
 

- sean

On Wed, Nov 5, 2025, 23:03 Toby Allsopp <[email protected]> wrote:
The doc comment for database/sql/(*DB).Close says:

// Close closes the database and prevents new queries from starting.
// Close then waits for all queries that have started processing on the server
// to finish.
//
// It is rare to Close a [DB], as the [DB] handle is meant to be
// long-lived and shared between many goroutines.
func (db *DB) Close() error {

I was led astray for quite some time by the "Close then waits" part. I thought that meant that the Close method would block (or "wait") until all connections that had been issued from the pool had been returned to the pool and then closed. It turns out that this is not the case, and I think what the comment means is that in-use connections will be closed later, after Close returns, once they have completed their work.

I'm considering creating an issue for this and am wondering if anyone has an opinion on whether this is actually a problem with the documentation and whether it is worth raising.

Thanks,
Toby.

--
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/12486fef-8b92-410a-85b3-978c969640can%40googlegroups.com.

--
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/CAGabyPpz5iGkyWAM_K434p24FthLK7vu6Q9oRaWFP%3DjqofPsrQ%40mail.gmail.com.

--
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/DE67AF34-8B9A-44E9-BCB9-697877452BC8%40me.com.

Reply via email to