I know what's causing it and I'm dealing with it now

take a look at this code from database/sql
if the execution of the resultFromStatement function panics, then releaseConn will never be executed

func (s *Stmt) ExecContext(ctx context.Context, args ...interface{}) (Result, error) {
	s.closemu.RLock()
	defer s.closemu.RUnlock()

	var res Result
	strategy := cachedOrNewConn
	for i := 0; i < maxBadConnRetries+1; i++ {
		if i == maxBadConnRetries {
			strategy = alwaysNewConn
		}
		dc, releaseConn, ds, err := s.connStmt(ctx, strategy)
		if err != nil {
			if err == driver.ErrBadConn {
				continue
			}
			return nil, err
		}

		res, err = resultFromStatement(ctx, dc.ci, ds, args...)     // PANIC HERE!
		releaseConn(err)      // NEVER EXECUTED
		if err != driver.ErrBadConn {
			return res, err
		}
	}
	return nil, driver.ErrBadConn
}

This can happen if we implement a Valuer interface where panic occurs
I've seen libraries that use the reflect package inaccurately before and create a panic at this point

https://go-review.googlesource.com/c/go/+/382214

Change https://golang.org/cl/382214 mentions this issue: database/sql: Stmt improved for more panic-stability

Yes, Valuer must not panic:

type Valuer interface {
	// Value returns a driver Value.
	// Value must not panic.
	Value() (Value, error)
}

To date I've not wanted to fix this.
I'll see if I can look at your CL to see how invasive this change is.

Yes, Valuer must not panic

it's not just about Valuer any panic in this thread will cause the gorutine to freeze
I recently sent a fix to this library: https://github.com/ClickHouse/clickhouse-go
it was panic that caused freezing and Valuer was not used there

. . .
database/sql 
  sql.go:2595
    res, err = resultFromStatement(ctx, dc.ci, ds, args...)
  sql.go:2622
    resi, err := ctxDriverStmtExec(ctx, ds.si, dargs)
  ctxutil.go:65
    return siCtx.ExecContext(ctx, nvdargs)

further down the stack, the library that implements low-level operations - panics

This is the example I came across when I discovered this error

There was no use of Valuer

Fair enough. I've heard you. I'll see what we can do.

I tried to reproduce in the test the call stack that leads to the error. To do this I had to implement a couple of driver interfaces. This shows that we are not protected against applications freezing if the driver that can panic when executing Exec or Query.

When goroutine is frozen, we can't complete the test, so I added a 15-second timeout

In any case, I corrected the tests today to make the problem I'm solving even clearer
https://golang.org/cl/382214