delta/go-git.git/src/database, branch dev.typealias

[release-branch.go1.8] database/sql: ensure releaseConn is defined before a possible close

2017-05-23T19:41:50+00:00

Applies https://golang.org/cl/42139 to the go1.8 release branch.

Also correct two minor issues detected with go vet.

Fixes #20217

Change-Id: I2c41af9497493598fbcfc140439b4e25b9bb7e72
Reviewed-on: https://go-review.googlesource.com/42532
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot 
Reviewed-by: Chris Broadfoot

[release-branch.go1.8] database/sql: convert test timeouts to explicit waits with checks

2017-02-13T19:22:34+00:00

When testing context cancelation behavior do not rely on context
timeouts. Use explicit checks in all such tests. In closeDB
convert the simple check for zero open conns with a wait loop
for zero open conns.

Fixes #19024
Fixes #19041

Change-Id: Iecfcc4467e91249fceb21ffd1f7c62c58140d8e9
Reviewed-on: https://go-review.googlesource.com/36902
Run-TryBot: Daniel Theophanes 
TryBot-Result: Gobot Gobot 
Reviewed-by: Russ Cox 
Reviewed-on: https://go-review.googlesource.com/36917
Run-TryBot: Brad Fitzpatrick 
Reviewed-by: Daniel Theophanes

[release-branch.go1.8] database/sql: ensure driverConns are closed if not returned to pool

2017-02-10T17:53:36+00:00

Previously if a connection was requested but timed out during the
request and when acquiring the db.Lock the connection request
is fulfilled and the request is unable to be returned to the
connection pool, then then driver connection would not be closed.

No tests were added or modified because I was unable to determine
how to trigger this situation without something invasive.

Change-Id: I9d4dc680e3fdcf63d79d212174a5b8b313f363f1
Reviewed-on: https://go-review.googlesource.com/36641
Reviewed-by: Russ Cox 
Reviewed-on: https://go-review.googlesource.com/36714
Run-TryBot: Russ Cox 
TryBot-Result: Gobot Gobot 
Reviewed-by: Brad Fitzpatrick

[release-branch.go1.8] database/sql: do not exhaust connection pool on conn request timeout

2017-02-10T17:53:29+00:00

Previously if a context was canceled while it was waiting for a
connection request, that connection request would leak.

To prevent this remove the pending connection request if the
context is canceled and ensure no connection has been sent on the channel.
This requires a change to how the connection requests are represented in the DB.

Fixes #18995

Change-Id: I9a274b48b8f4f7ca46cdee166faa38f56d030852
Reviewed-on: https://go-review.googlesource.com/36563
Reviewed-by: Russ Cox 
Run-TryBot: Russ Cox 
TryBot-Result: Gobot Gobot 
Reviewed-on: https://go-review.googlesource.com/36613
Reviewed-by: Brad Fitzpatrick

[release-branch.go1.8] database/sql: record the context error in Rows if canceled

2017-02-09T03:47:26+00:00

Previously it was intended that Rows.Scan would return
an error and Rows.Err would return nil. This was problematic
because drivers could not differentiate between a normal
Rows.Close or a context cancel close.

The alternative is to require drivers to return a Scan to return
an error if the driver is closed while there are still rows to be read.
This is currently not how several drivers currently work and may be
difficult to detect when there are additional rows.

At the same time guard the the Rows.lasterr and prevent a close
while a Rows operation is active.

For the drivers that do not have Context methods, do not check for
context cancelation after the operation, but before for any operation
that may modify the database state.

Fixes #18961

Change-Id: I49a25318ecd9f97a35d5b50540ecd850c01cfa5e
Reviewed-on: https://go-review.googlesource.com/36485
Reviewed-by: Russ Cox 
Run-TryBot: Russ Cox 
TryBot-Result: Gobot Gobot 
Reviewed-on: https://go-review.googlesource.com/36614
Reviewed-by: Brad Fitzpatrick

database/sql: fix race when canceling queries immediately

2017-01-26T06:25:37+00:00

Previously the following could happen, though in practice it would
be rare.

Goroutine 1:
	(*Tx).QueryContext begins a query, passing in userContext

Goroutine 2:
	(*Tx).awaitDone starts to wait on the context derived from the passed in context

Goroutine 1:
	(*Tx).grabConn returns a valid (*driverConn)
	The (*driverConn) passes to (*DB).queryConn

Goroutine 3:
	userContext is canceled

Goroutine 2:
	(*Tx).awaitDone unblocks and calls (*Tx).rollback
	(*driverConn).finalClose obtains dc.Mutex
	(*driverConn).finalClose sets dc.ci = nil

Goroutine 1:
	(*DB).queryConn obtains dc.Mutex in withLock
	ctxDriverPrepare accepts dc.ci which is now nil
	ctxCriverPrepare panics on the nil ci

The fix for this is to guard the Tx methods with a RWLock
holding it exclusivly when closing the Tx and holding a read lock
when executing a query.

Fixes #18719

Change-Id: I37aa02c37083c9793dabd28f7f934a1c5cbc05ea
Reviewed-on: https://go-review.googlesource.com/35550
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot 
Reviewed-by: Brad Fitzpatrick

database/sql: let tests wait for db pool to come to expected state

2017-01-25T21:57:28+00:00

Slower builders were failing TestQueryContext because the cancel
and return to conn pool happens async. TestQueryContext already
uses a wait method for this reason. Use the same method for
other context tests.

Fixes #18759

Change-Id: I84cce697392b867e4ebdfadd38027a06ca14655f
Reviewed-on: https://go-review.googlesource.com/35750
Reviewed-by: Brad Fitzpatrick 
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot

all: fix misspellings

2017-01-07T16:53:25+00:00

Change-Id: I429637ca91f7db4144f17621de851a548dc1ce76
Reviewed-on: https://go-review.googlesource.com/34923
Reviewed-by: Ian Lance Taylor 
Reviewed-by: Daniel Martí 
Run-TryBot: Ian Lance Taylor 
TryBot-Result: Gobot Gobot

database/sql: fix typo and wording

2017-01-02T22:17:24+00:00

Clean up the phrasing a little bit, make the comment fit in 80
characters, and fix the spelling of "guard."

Change-Id: I688a3e760b8d67ea83830635f64dff04dd9a5911
Reviewed-on: https://go-review.googlesource.com/34792
Reviewed-by: Brad Fitzpatrick

database/sql: prevent Tx.rollback from racing Tx.close

2017-01-02T20:21:02+00:00

Previously Tx.done was being set in close, but in a Tx
rollback and Commit are the real closing methods,
and Tx.close is just a helper common to both. Prior to this
change a multiple rollback statements could be called, one
would enter close and begin closing it while the other was
still in rollback breaking it. Fix that by setting done
in rollback and Commit, not in Tx.close.

Fixes #18429

Change-Id: Ie274f60c2aa6a4a5aa38e55109c05ea9d4fe0223
Reviewed-on: https://go-review.googlesource.com/34716
Reviewed-by: Brad Fitzpatrick 
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot