Fork of Go programming language with my patches. http://git.kilabit.info/go/atom?h=main 2014-09-08T04:08:51Z 2014-09-08T04:08:51Z Russ Cox rsc@golang.org 2014-09-08T04:08:51Z urn:sha1:c007ce824d9a4fccb148f9204e04c23ed2984b71 Preparation was in CL 134570043. This CL contains only the effect of 'hg mv src/pkg/* src'. For more about the move, see golang.org/s/go14nopkg. 2014-09-02T16:08:41Z Marko Tiikkaja marko@joh.to 2014-09-02T16:08:41Z urn:sha1:90e2e2b89633770d42f2ff558588dfc53c3288c8 Previously, if all connections were busy, we would always re-prepare the statement on the connection we were assigned from the pool. That meant that if all connections were busy most of the time, the number of prepared statements for each connection would keep increasing over time. Instead, after getting a free connection, check to see if the statement has already been prepared on it, and reuse the statement handle if so. LGTM=bradfitz R=golang-codereviews, gobot, bradfitz CC=golang-codereviews https://golang.org/cl/116930043 2014-08-28T15:49:56Z Alberto García Hierro alberto@garciahierro.com 2014-08-28T15:49:56Z urn:sha1:6fb6f4e7f9eea8b724ddde592686d7e9dcdaa41c Significantly reduces the number of allocations, while also simplifying the code and increasing performance by a 1-2%. benchmark old ns/op new ns/op delta BenchmarkConcurrentDBExec 13290567 13026236 -1.99% BenchmarkConcurrentStmtQuery 13249399 13008879 -1.82% BenchmarkConcurrentStmtExec 8806237 8680182 -1.43% BenchmarkConcurrentTxQuery 13628379 12756293 -6.40% BenchmarkConcurrentTxExec 4794800 4722440 -1.51% BenchmarkConcurrentTxStmtQuery 5040804 5200721 +3.17% BenchmarkConcurrentTxStmtExec 1366574 1336626 -2.19% BenchmarkConcurrentRandom 11119120 10926113 -1.74% benchmark old allocs new allocs delta BenchmarkConcurrentDBExec 14191 13684 -3.57% BenchmarkConcurrentStmtQuery 16020 15514 -3.16% BenchmarkConcurrentStmtExec 4179 3672 -12.13% BenchmarkConcurrentTxQuery 16025 15518 -3.16% BenchmarkConcurrentTxExec 12717 12709 -0.06% BenchmarkConcurrentTxStmtQuery 15532 15525 -0.05% BenchmarkConcurrentTxStmtExec 2175 2168 -0.32% BenchmarkConcurrentRandom 12320 11997 -2.62% benchmark old bytes new bytes delta BenchmarkConcurrentDBExec 2164827 2139760 -1.16% BenchmarkConcurrentStmtQuery 2418070 2394030 -0.99% BenchmarkConcurrentStmtExec 1728782 1704371 -1.41% BenchmarkConcurrentTxQuery 2477144 2452620 -0.99% BenchmarkConcurrentTxExec 588920 588343 -0.10% BenchmarkConcurrentTxStmtQuery 790866 796578 +0.72% BenchmarkConcurrentTxStmtExec 98502 98143 -0.36% BenchmarkConcurrentRandom 1725906 1710220 -0.91% LGTM=ruiu, dave, bradfitz R=golang-codereviews, ruiu, gobot, bradfitz, dave, minux CC=bradfitz, golang-codereviews https://golang.org/cl/107020044 2014-07-16T23:29:51Z Robert Griesemer gri@golang.org 2014-07-16T23:29:51Z urn:sha1:8a23c0021edad5bbf117b71ee7db32406b0c9a67 Pending CL 113120043. LGTM=dave R=golang-codereviews, dave CC=golang-codereviews https://golang.org/cl/112290043 2014-04-29T16:44:40Z Robert Hencke robert.hencke@gmail.com 2014-04-29T16:44:40Z urn:sha1:f999e14f025b69516dd3e126d04dd309adb2fce0 LGTM=ruiu, bradfitz R=golang-codereviews, bradfitz, ruiu CC=golang-codereviews https://golang.org/cl/91840044 2013-12-26T19:27:18Z Marko Tiikkaja marko@joh.to 2013-12-26T19:27:18Z urn:sha1:0d12e24ebb037202c3324c230e075f1e448f6f34 The last connection in the pool was not being handed out correctly. R=golang-codereviews, gobot, bradfitz CC=golang-codereviews https://golang.org/cl/40410043 2013-12-17T19:57:30Z Julien Schmidt google@julienschmidt.com 2013-12-17T19:57:30Z urn:sha1:762a9d934eab267418595df7a220eec50919b77d This also fixes several connection leaks. Fixes #5718 R=bradfitz, adg CC=alberto.garcia.hierro, golang-dev https://golang.org/cl/14920046 2013-12-16T20:48:35Z Marko Tiikkaja marko@joh.to 2013-12-16T20:48:35Z urn:sha1:1f20ab1116ab6cb0b77e22ffba3de9919e9def50 The previous coding did not correctly check for errors from the driver's Next() or Close(), which could mask genuine errors from the database, as witnessed in issue #6651. Even after this change errors from Close() will be ignored if the query returned no rows (as Rows.Next will have closed the handle already), but it is a lot easier for the drivers to guard against that. Fixes #6651. R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/41590043 2013-10-16T16:22:57Z Alberto García Hierro alberto@garciahierro.com 2013-10-16T16:22:57Z urn:sha1:37db8804691f0a5e618cbc041909895c9709263c CL 10726044 introduced a race condition which causes connections to be leaked under certain circumstances. If SetMaxOpenConns is used, the application eventually deadlocks. Otherwise, the number of open connections just keep growing indefinitely. Fixes #6593 R=golang-dev, bradfitz, tad.glines, bketelsen CC=golang-dev https://golang.org/cl/14611045 2013-10-16T16:17:25Z Alberto García Hierro alberto@garciahierro.com 2013-10-16T16:17:25Z urn:sha1:478f4b67543824c039d2f7afec6af88a59148db2 Add a check at the end of every test to make sure there are no leaked connections after running a test. Avoid incorrectly decrementing the number of open connections when the driver connection ends up it a bad state (numOpen was decremented twice). Prevent leaking a Rows struct (which ends up leaking a connection) in Row.Scan() when a *RawBytes destination is improperly used. Close the Rows struct in TestRowsColumns. Update #6593 R=golang-dev, bradfitz, dave CC=golang-dev https://golang.org/cl/14642044