go/src/database/sql/sql_test.go, branch bench-before

all: simplify bool conditions

2023-09-20T18:06:13Z

Change-Id: Id2079f7012392dea8dfe2386bb9fb1ea3f487a4a Reviewed-on: https://go-review.googlesource.com/c/go/+/526015 Reviewed-by: Matthew Dempsky Auto-Submit: Ian Lance Taylor Reviewed-by: Ian Lance Taylor LUCI-TryBot-Result: Go LUCI Reviewed-by: qiulaidongfeng <2645477756@qq.com>

database/sql: add Null[T]

2023-08-07T14:26:37Z

Generic version of NullString, NullInt64, etc. Fixes #60370 Change-Id: I166a05a6126e8b8571db5cbb026303bb6551d56b GitHub-Last-Rev: 3c8d2d5141c36f034d2124e19ee090620363ba24 GitHub-Pull-Request: golang/go#60677 Reviewed-on: https://go-review.googlesource.com/c/go/+/501700 Reviewed-by: Jonathan Amsterdam TryBot-Result: Gopher Robot Run-TryBot: Ian Lance Taylor Reviewed-by: Russ Cox

database/sql: prevent internal context error from being returned from Rows.Err()

2023-07-05T17:10:36Z

CL 497675 modified Rows such that context errors are propagated through Rows.Err(). This caused an issue where calling Close meant that an internal cancellation error would (eventually) be returned from Err: 1. A caller makes a query using a cancellable context. 2. initContextClose sees that either the query context or the transaction context can be canceled, so will need to spawn a goroutine to capture their errors. 3. initContextClose derives a context from the query context via WithCancel and sets rs.cancel. 4. When a user calls Close, rs.cancel is called. awaitDone's ctx is cancelled, which is good, since we don't want it to hang forever. 5. This internal cancellation (after CL 497675) has its error saved on contextDone. 6. Later, calling Err will return the error in contextDone if present. This leads to a race condition depending on how quickly Err is called after Close. The docs for Close and Err state that calling Close should have no affect on the return result for Err. So, a potential fix is to ensure that awaitDone does not save the error when the cancellation comes from a Close via rs.cancel. This CL does that, using a new context not derived from the query context, whose error is ignored as the query context's error used to be before the original bugfix. The included test fails before the CL, and passes afterward. Fixes #60932 Change-Id: I2bf4c549efd83d62b86e298c9c45ebd06a3ad89a Reviewed-on: https://go-review.googlesource.com/c/go/+/505397 Auto-Submit: Russ Cox Run-TryBot: Russ Cox TryBot-Result: Gopher Robot Reviewed-by: Russ Cox Reviewed-by: Dmitri Shuralyov Reviewed-by: Brad Fitzpatrick

database/sql: fix flake in TestContextCancelDuringRawBytesScan

2023-06-13T19:41:21Z

If the cancellation takes effect between Next and Scan, then Scan returns context.Canceled, but the test wasn't allowing this case. The old flake reproduced easily with: go test -c stress ./sql.test -test.count=100 -test.run=TestContextCancelDuringRawBytesScan The new test modes exercise that path directly instead of needing stress. The new check for context.Canceled fixes the new test mode "top". Fixes #60445. Change-Id: I3870039a0fbe0a43c3e261b43b175ef83f818765 Reviewed-on: https://go-review.googlesource.com/c/go/+/502876 Reviewed-by: Ian Lance Taylor TryBot-Result: Gopher Robot Reviewed-by: Brad Fitzpatrick Auto-Submit: Russ Cox Run-TryBot: Russ Cox

database/sql: fix regression from earlier RawBytes fix

2023-05-26T03:06:19Z

The earlier CL 497675 for #60304 introduced a behavior change that, while not strictly a bug, caused a bunch of test failures in a large codebase. Rather than add behavior changes in a 10 year old package, revert to the old behavior: a context cancelation between Rows.Next reporting false and a call to Rows.Err should not result in Rows.Err returning the context error. That behavior was accidentally added in CL 497675 as part of changing how contexts and Rows iteration worked. Updates #60304 Updates #53970 Change-Id: I22f8a6a6b0b5a94b430576cf50e015efd01ec652 Reviewed-on: https://go-review.googlesource.com/c/go/+/498398 Run-TryBot: Brad Fitzpatrick Reviewed-by: Russ Cox Reviewed-by: Ian Lance Taylor TryBot-Result: Gopher Robot

database/sql: make RawBytes safely usable with contexts

2023-05-24T04:00:19Z

sql.RawBytes was added the very first Go release, Go 1. Its docs say: > RawBytes is a byte slice that holds a reference to memory owned by > the database itself. After a Scan into a RawBytes, the slice is only > valid until the next call to Next, Scan, or Close. That "only valid until the next call" bit was true at the time, until contexts were added to database/sql in Go 1.8. In the past ~dozen releases it's been unsafe to use QueryContext with a context that might become Done to get an *sql.Rows that's scanning into a RawBytes. The Scan can succeed, but then while the caller's reading the memory, a database/sql-managed goroutine can see the context becoming done and call Close on the database/sql/driver and make the caller's view of the RawBytes memory no longer valid, introducing races, crashes, or database corruption. See #60304 and #53970 for details. This change does the minimal surgery on database/sql to make it safe again: Rows.Scan was already acquiring a mutex to check whether the rows had been closed, so this change make Rows.Scan notice whether *RawBytes was used and, if so, doesn't release the mutex on exit before returning. That mean it's still locked while the user code operates on the RawBytes memory and the concurrent context-watching goroutine to close the database still runs, but if it fires, it then gets blocked on the mutex until the next call to a Rows method (Next, NextResultSet, Err, Close). Updates #60304 Updates #53970 (earlier one I'd missed) Change-Id: Ie41c0c6f32c24887b2f53ec3686c2aab73a1bfff Reviewed-on: https://go-review.googlesource.com/c/go/+/497675 TryBot-Result: Gopher Robot Reviewed-by: Ian Lance Taylor Run-TryBot: Brad Fitzpatrick Auto-Submit: Ian Lance Taylor Reviewed-by: Russ Cox

database/sql: remove a distracting alloc, use atomic.Bool

2023-03-14T20:34:27Z

This removes an allocation in Conn.grabConn that, while not super important, was distracting me when optimizing code elsewhere. While here, convert an atomic that was forgotten when this package was earlier updated to use the new Go 1.19 typed atomics. Change-Id: I4666256b4c0512e2162bd485c389130699f9d5ed Reviewed-on: https://go-review.googlesource.com/c/go/+/475415 Reviewed-by: David Crawshaw Reviewed-by: Ian Lance Taylor TryBot-Result: Gopher Robot Reviewed-by: Cherry Mui Run-TryBot: Brad Fitzpatrick

database/sql: make TestTxContextWaitNoDiscard test more robust

2022-07-11T17:14:33Z

Similar to CL 385934, rely on waiter trigger instead of the WAIT query prefix and factor out the common test code. Fixes #53222 Change-Id: I46efc85ca102b350bb4dbe8e514921e016870ffb Reviewed-on: https://go-review.googlesource.com/c/go/+/416655 Reviewed-by: Michael Knyszek TryBot-Result: Gopher Robot Auto-Submit: Bryan Mills Run-TryBot: Dmitri Goutnik Reviewed-by: Bryan Mills

database/sql: fix close rows error ignored in Next

2022-05-19T20:21:12Z

Change-Id: I19f0d764e2a6122307f3f26a6dd3be7b1155c73b GitHub-Last-Rev: 9f1f883c452201679a2d2af2cc29de0f09a43f28 GitHub-Pull-Request: golang/go#52756 Reviewed-on: https://go-review.googlesource.com/c/go/+/404794 Reviewed-by: Daniel Theophanes Reviewed-by: Bryan Mills Reviewed-by: Michael Knyszek Run-TryBot: Daniel Theophanes TryBot-Result: Gopher Robot

all: fix spelling

2022-05-17T19:51:29Z

Change-Id: I68538a50c22b02cdb5aa2a889f9440fed7b94c54 GitHub-Last-Rev: aaac9e78340ac482e9cd1b506a035f271c29648c GitHub-Pull-Request: golang/go#52944 Reviewed-on: https://go-review.googlesource.com/c/go/+/406835 Reviewed-by: Bryan Mills Reviewed-by: Robert Griesemer TryBot-Result: Gopher Robot Run-TryBot: Bryan Mills Auto-Submit: Bryan Mills