/cc @bradfitz @kardianos

Cause:

1. You are pulling out a single connection from the pool.
2. You are not closing a row, either by finishing reading rows or by calling rows.Close()
3. The conn is waiting for the row to be done, which it never is.

I'm not sure this is a problem, much less fixable.

maybe Conn.Close could ensure any rows are also closed.

I'm not sure this is a problem

... until your unit tests mysteriously stop working (and don't report deadlock because of httptest.Server running in parallel).

maybe Conn.Close could ensure any rows are also closed.

Another approach might be to include some stronger wording in the documentation. Instead of
https://golang.org/pkg/database/sql/#Rows.Close

Close closes the Rows, preventing further enumeration. [...]

maybe

Close closes the Rows, preventing further enumeration and allowing the connection to free associated resources. [...]

@Drahflow: Just a suggestion.

Why use context which is never canceled? It can be used to clean up any pending Rows or other operations on the connection. Just cancel the context before closing. (So defer cancel() comes after defer con.Close().

ctx, cancel := context.WithCancel(context.Background())
        con, err := db.Conn(ctx)
        if err != nil {
 		cancel() // make sure context does not leak
                panic(err)
        }
        defer con.Close()
	defer cancel()

https://play.golang.org/p/ZH0A-c8VKB_y

... until your unit tests mysteriously stop working (and don't report deadlock because of httptest.Server running in parallel).

That's what contexts can be used for. You can also set fixed timeouts in your unit tests with context.WithTimeout, so that an error is thrown back when the timeout passes, for example context.DeadlineExceeded. This way there will be less mystery.