by awpritchard:

go version: the particular manifestation of this I'm hitting reproduces from
231af8ac63aa (scheduler changes that almost certainly are only revealing the problem,
not causing it) through tip (9bb42a7021c9).

see database/sql/sql.go:1308:
> func (rs *Rows) Close() error {
>    if rs.closed {
>        return nil
>    }
>    rs.closed = true
>    err := rs.rowsi.Close()
>    rs.releaseConn(err)
>    if rs.closeStmt != nil {
>        rs.closeStmt.Close()
>    }
>    return err
> }

This puts the Rows' connection back into the idle pool, and then calls the
driver.Stmt.Close method of the Stmt it belongs to.  In the postgresql driver
implementation (https://github.com/lib/pq), Stmt.Close communicates with the server (on
the connection that was just put back into the idle pool).  Most of the time, this
causes no problems, but if another goroutine makes a query at the right (wrong?) time,
chaos results.

Providing steps to reproduce is difficult, since it would have to involve multiple
packages and force a race condition to occur.

Moving the call to releaseConn to after the Stmt.Close fixes the problem in my case;
but, there are other places that Close a Stmt after releasing its connection.

In any case, traffic is being sent on "free" connections shortly after they
are freed, leading to race conditions that kill the driver code.

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
64-bit Linux, 3.7.7

Which version are you using?  (run 'go version')
go version devel +9bb42a7021c9 Thu Apr 11 13:40:14 2013 -0700 linux/amd64

Please provide any additional information below.