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

all: fix field names

2023-11-27T15:48:25Z

Change-Id: I3ad7a50707486ebdbbd676b3581df6e3ed0fd3a1 Reviewed-on: https://go-review.googlesource.com/c/go/+/543476 Auto-Submit: Dmitri Shuralyov TryBot-Result: Gopher Robot Reviewed-by: Keith Randall Reviewed-by: Keith Randall Reviewed-by: Dmitri Shuralyov Run-TryBot: shuang cui

database/sql: add godoc links

2023-10-23T09:04:12Z

Add godoc links in database/sql and database/sql/driver. Change-Id: I96ed79645a7cc656f5d23450ba3cfe005b04b31a Reviewed-on: https://go-review.googlesource.com/c/go/+/486815 LUCI-TryBot-Result: Go LUCI Reviewed-by: Ian Lance Taylor Reviewed-by: Benny Siegert

database: add available godoc link

2023-10-18T19:51:24Z

Change-Id: I6150858f1186edc6cebd38ff166d57287fa430f9 Reviewed-on: https://go-review.googlesource.com/c/go/+/535078 Reviewed-by: Carlos Amedee Reviewed-by: Ian Lance Taylor Run-TryBot: shuang cui TryBot-Result: Gopher Robot Auto-Submit: Ian Lance Taylor

database/sql: use the built-in min function

2023-10-03T19:29:35Z

Change-Id: Ib6a0e1e1583e45e3d239455e8b131c81602b2d5d GitHub-Last-Rev: dc82635562a7fb4488f374d7a9ed26b29310e918 GitHub-Pull-Request: golang/go#63200 Reviewed-on: https://go-review.googlesource.com/c/go/+/530875 Reviewed-by: qiulaidongfeng <2645477756@qq.com> Reviewed-by: Ian Lance Taylor Reviewed-by: Michael Pratt Auto-Submit: Ian Lance Taylor LUCI-TryBot-Result: Go LUCI

database/sql: use reflect.TypeFor for known types

2023-08-08T20:57:57Z

For #60088 Change-Id: Ib05ba3d456b22f7370459037b3d263c4b3ebe3b1 Reviewed-on: https://go-review.googlesource.com/c/go/+/514975 Reviewed-by: Daniel Theophanes Run-TryBot: Ian Lance Taylor TryBot-Result: Gopher Robot Reviewed-by: Ian Lance Taylor Run-TryBot: Ian Lance Taylor Auto-Submit: Ian Lance Taylor Reviewed-by: Michael Knyszek

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

src/database/sql: run gofmt

2023-07-07T20:48:55Z

Run gofmt on a source file. Change-Id: I180d5cc7425fc5d8e9cf63005ac692f361beb1ed Reviewed-on: https://go-review.googlesource.com/c/go/+/508497 Run-TryBot: Than McIntosh Reviewed-by: Eli Bendersky TryBot-Result: Gopher Robot

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 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