delta/go-git.git/src/database/sql/sql_test.go, branch dev.go2go

database/sql: close driver.Connector if it implements io.Closer

2021-02-25T19:34:27+00:00

This change allows driver implementations to manage resources in
driver.Connector, e.g. to share the same underlying database handle
between multiple connections. That is, it allows embedded databases
with in-memory backends like SQLite and Genji to safely release the
resources once the sql.DB is closed.

This makes it possible to address oddities with in-memory stores in
SQLite and Genji drivers without introducing too much complexity in
the driver implementations.

See also:
- https://github.com/mattn/go-sqlite3/issues/204
- https://github.com/mattn/go-sqlite3/issues/511
- https://github.com/genjidb/genji/issues/210

Fixes #41790

Change-Id: Idbd19763134438ed38288b9d44f16608e4e97fd7
GitHub-Last-Rev: 962c785dfb3bb6ad98b2216bcedd84ba383fe872
GitHub-Pull-Request: golang/go#41710
Reviewed-on: https://go-review.googlesource.com/c/go/+/258360
Reviewed-by: Emmanuel Odeke 
Reviewed-by: Daniel Theophanes 
Trust: Emmanuel Odeke 
Run-TryBot: Emmanuel Odeke 
TryBot-Result: Go Bot

database: remove race in TestTxContextWait

2021-02-24T14:10:04+00:00

This test contained a data race.
On line 437, db.BeginTx starts a goroutine that runs tx.awaitDone,
which reads tx.keepConnOnRollback.
On line 445, the test writes to tx.keepConnOnRollback.
tx.awaitDone waits on ctx, but because ctx is timeout-based,
there's no ordering guarantee between the write and the read.

The race detector never caught this before
because the context package implementation of Done
contained enough synchronization to make it safe.
That synchronization is not package of the context API or guarantees,
and the first several releases it was not present.
Another commit soon will remove that synchronization,
exposing the latent data race.

To fix the race, emulate a time-based context
using an explicit cancellation-based context.
This gives us enough control to avoid the race.

Change-Id: I103fe9b987b1d4c02e7a20ac3c22a682652128b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/288493
Trust: Josh Bleecher Snyder 
Run-TryBot: Josh Bleecher Snyder 
TryBot-Result: Go Bot 
Reviewed-by: Daniel Theophanes

database/sql, runtime: correct *.Fatal inside goroutines in tests

2020-10-31T20:30:19+00:00

Found by go vet pass "testinggoroutines".

Change-Id: I6360af2079617b7aa62dcb9bd7254578ca5d1c1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/235527
Run-TryBot: Emmanuel Odeke 
Reviewed-by: Ian Lance Taylor 
Trust: Emmanuel Odeke

database/sql: fix TestTxStmtDeadlock test

2020-10-29T00:19:20+00:00

Drop error check because errors can be
not only ErrTxDone for tx stmt executions,
and the purpose of the test is just reproducing
deadlock.

Fixes #42259

Change-Id: I9e7105ada1403ec7064dcc1c3385b36893a1c195
Reviewed-on: https://go-review.googlesource.com/c/go/+/266097
Reviewed-by: Daniel Theophanes 
Trust: Emmanuel Odeke 
Run-TryBot: Emmanuel Odeke 
TryBot-Result: Go Bot

database/sql: fix tx stmt deadlock when rollback

2020-10-28T16:55:17+00:00

Tx acquires tx.closemu W-lock and then acquires stmt.closemu.W-lock
to fully close the transaction and associated prepared statement.
Stmt query and execution run in reverse ways - acquires
stmt.closemu.R-lock and then acquires tx.closemu.R-lock to grab tx
connection, which may cause deadlock.

Prevent the lock is held around tx.closePrepared to ensure no
deadlock happens.

Fixes #40985

Change-Id: If53909822b87bce11861a6e3035ecb9476d2cd17
Reviewed-on: https://go-review.googlesource.com/c/go/+/250178
Run-TryBot: Emmanuel Odeke 
TryBot-Result: Go Bot 
Reviewed-by: Daniel Theophanes 
Trust: Emmanuel Odeke

database/sql: make Rows.Scan properly wrap underlying errors

2020-08-14T17:45:39+00:00

The prior implementation used the format verb %v which unfortunately
improperly wrapped any underlying scanner errors, and we couldn't use
errors.Is nor errors.As. This change fixes that by using the %w verb.

Added a unit to ensure that both error sub string matching works, but
also that errors.Is works as expected.

Fixes #38099

Change-Id: Iea667041dd8081d961246f77f2542330417292dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/248337
Reviewed-by: Emmanuel Odeke 
Reviewed-by: Daniel Theophanes 
Run-TryBot: Emmanuel Odeke 
TryBot-Result: Gobot Gobot

database/sql: de-flake TestTxCannotCommitAfterRollback

2020-04-22T22:10:09+00:00

Do not cancel rows during test. Only cancel the Tx.
Correct the referenced issue number on the test.

Fixes #38597

Change-Id: I0e8ba1bf2a8ba638d121c9c6938501fec1d5e961
Reviewed-on: https://go-review.googlesource.com/c/go/+/229478
Run-TryBot: Daniel Theophanes 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor

database/sql: on Tx rollback, retain connection if driver can reset session

2020-04-20T18:47:26+00:00

Previously the Tx would drop the connection after rolling back from
a context cancel. Now if the driver can reset the session,
keep the connection.

Change-Id: Ie6a3124275632787629844d91a06bb2e70cc060b
Reviewed-on: https://go-review.googlesource.com/c/go/+/216241
Reviewed-by: Emmanuel Odeke 
Run-TryBot: Emmanuel Odeke 
TryBot-Result: Gobot Gobot

database/sql: prevent Tx statement from committing after rollback

2020-04-20T17:45:50+00:00

It was possible for a Tx that was aborted for rollback
asynchronously to execute a query after the rollback had completed
on the database, which often would auto commit the query outside
of the transaction.

By W-locking the tx.closemu prior to issuing the rollback
connection it ensures any Tx query either fails or finishes
on the Tx, and never after the Tx has rolled back.

Fixes #34775
Fixes #32942

Change-Id: I017b7932082f2f4ead70bae08b61ed9068ac1d01
Reviewed-on: https://go-review.googlesource.com/c/go/+/216240
Reviewed-by: Emmanuel Odeke

database/sql: check conn expiry when returning to pool, not when handing it out

2020-04-20T17:41:27+00:00

With the original connection reuse strategy, it was possible that
when a new connection was requested, the pool would wait for an
an existing connection to return for re-use in a full connection
pool, and then it would check if the returned connection was expired.
If the returned connection expired while awaiting re-use, it would
return an error to the location requestiong the new connection.
The existing call sites requesting a new connection was often the last
attempt at returning a connection for a query. This would then
result in a failed query.

This change ensures that we perform the expiry check right
before a connection is inserted back in to the connection pool
for while requesting a new connection. If requesting a new connection
it will no longer fail due to the connection expiring.

Fixes #32530

Change-Id: If16379befe0e14d90160219c0c9396243fe062f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/216197
Reviewed-by: Emmanuel Odeke