sql: deflake TestSavepoints#73388
Conversation
|
This change is |
andreimatei
left a comment
There was a problem hiding this comment.
Reviewable status:
complete! 0 of 0 LGTMs obtained (waiting on @nvanbenschoten and @rytaft)
pkg/sql/conn_executor_savepoints_test.go, line 50 at r1 (raw file):
return conn } conn = serverutils.OpenDBConn(
this is too heavy weight I think. You're creating a new connection pool when all you want is one connection. There's DB.Conn() instead, isn't there?
nvb
left a comment
There was a problem hiding this comment.
Reviewable status:
pkg/sql/conn_executor_savepoints_test.go, line 50 at r1 (raw file):
Previously, andreimatei (Andrei Matei) wrote…
this is too heavy weight I think. You're creating a new connection pool when all you want is one connection. There's
DB.Conn()instead, isn't there?
Is this creating a new connection pool? This is the same code that's in serverutils.StartServer (where origConn came from). And I don't see a DB.Conn().
andreimatei
left a comment
There was a problem hiding this comment.
Reviewable status:
pkg/sql/conn_executor_savepoints_test.go, line 50 at r1 (raw file):
Previously, nvanbenschoten (Nathan VanBenschoten) wrote…
Is this creating a new connection pool? This is the same code that's in
serverutils.StartServer(whereorigConncame from). And I don't see aDB.Conn().
origConn is a conn pool (a sql.DB).
Here's the Conn.
https://pkg.go.dev/database/sql#DB.Conn
rytaft
left a comment
There was a problem hiding this comment.
Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status:
b8145c9 to
7856323
Compare
nvb
left a comment
There was a problem hiding this comment.
Reviewable status:
pkg/sql/conn_executor_savepoints_test.go, line 50 at r1 (raw file):
Previously, andreimatei (Andrei Matei) wrote…
origConnis a conn pool (asql.DB).
Here's theConn.
https://pkg.go.dev/database/sql#DB.Conn
Oh I see, you're completely right. Thanks for calling this out. Done.
andreimatei
left a comment
There was a problem hiding this comment.
Reviewable status:
Fixes cockroachdb#70220. Fixes cockroachdb#72911. This commit deflakes `TestSavepoints` by running the manipulation of the `progress` table in a separate SQL connection. This connection is not subject to the lock_timeout or any other session settings that may be configured on the other SQL connections in the test.
7856323 to
c312eb0
Compare
|
TFTRs! bors r+ |
|
Build succeeded: |
73475: kvclient: cleanup legacy TxnHeartbeating field r=andreimatei a=andreimatei This field indicates whether the txn heartbeat loop started. 21.2 is not reading this field; it's only writing it for compatibility with 21.1. So, it's no longer needed since we're working towards 22.1. Release note: None 73478: rangecache: fix a span use-after-Finish r=andreimatei a=andreimatei Lookups of range descriptors use a form of pretty unusual unstructured concurrency: a request spawns a goroutine that might outlive it (in case the request is canceled), but at the same time the goroutine wants to be part of the same trace as the request. Before this patch, the goroutine was responsible for forking the request's span asynchronously. This was pretty broken because the request's span might be finished by the time it's forked. This is a use-after-Finish, and I'm trying to stop tolerating such uses. This patch fixes it by forking the span synchronously. Release note: None 73494: sql: actually deflake TestSavepoints r=nvanbenschoten a=nvanbenschoten This PR rolls back #73388 and reworks the fix for #70220. #73388 was an incorrect fix because the test relies on the progress table being updated in the same transaction as the rest of the SQL logic. This ensures that progress updates are rolled back when the rest of the transaction is rolled back. I didn't catch this in the initial PR because I missed the fact that the test had been skipped on `master`, so the test appeared to be passing with the change. When I then tried to backport the change in #73492, CI caught the mistake. The PR then deflakes `TestSavepoints` by increasing the lock timeout significantly (from 1ms to 100ms) in the `rollback_after_lock_timeout` subtest. The test was flaky because after the transaction hits a lock timeout error, it performs an async rollback. If this async rollback hasn't grabbed latches by the time the next txn retry (with a different txn ID) finishes waiting out the lock_timeout when attempting to write to its progress, a lock timeout error would be thrown. This commit makes this extremely unlikely by increasing the lock timeout from 1ms to 100ms. With this new timeout, I've never seen the test flake under stress. 73515: roachtest: fix pgjdbc unexpected pass for ArrayTest in 22.1 r=rafiss a=ZhouXing19 fixes #73298 Release note: None 73525: kv/kvnemesis: skip TestKVNemesisSingleNode r=irfansharif a=irfansharif Refs: #73373 Reason: flaky test Generated by bin/skip-test. Release justification: non-production code changes Release note: None Co-authored-by: Andrei Matei <andrei@cockroachlabs.com> Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com> Co-authored-by: Jane Xing <zhouxing@uchicago.edu> Co-authored-by: irfan sharif <irfanmahmoudsharif@gmail.com>
Fixes #70220.
Fixes #72911.
This commit deflakes
TestSavepointsby running the manipulation of theprogresstable in a separate SQL connection. This connection is notsubject to the lock_timeout or any other session settings that may be
configured on the other SQL connections in the test.