You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary:
Currently, `ConcurrentTablespaceTest.testAlterIndexSetTablespace` has a concurrency bug due to the way `CyclicBarrier` is used.
The test starts two threads, one that does DDL and one that does DML, and has them each execute 12 statements. Before executing each statement, each thread calls `CyclicBarrier.await` to ensure they are executing the statements at the same time.
### The problem
The problem is when the DML thread can runs into retriable errors (which is expected)—if this happens, the statement is retried without incrementing the statement counter, but the thread calls `CyclicBarrier.await` before retrying the statement. This means that if thread A runs into an error on statement 10, it'll retry statement 10 but this retry will be synchronized with other threads' statement 11.
This causes an issue at the end of the test when the threads run into uneven numbers of errors; since `CyclicBarrier.await` waits until all threads call `await`, it's possible that one thread finishes executing, so it never calls `await`, but another thread is stuck waiting at `await`.
### The fix
We fix this by swapping out the `CyclicBarrier` for a `Phaser`--`CyclicBarrier` requires a fixed number of threads, while `Phaser` allows for a dynamic number of threads. Using the `Phaser`, we de-register threads that are done executing, allowing the remaining threads to continue execution afterwards.
Jira: DB-16543
Test Plan:
```
./yb_build.sh release --java-test org.yb.pgsql.ConcurrentTablespaceTest#testAlterIndexSetTablespace
```
Reviewers: sanketh, myang
Reviewed By: myang
Differential Revision: https://phorge.dev.yugabyte.com/D43992
0 commit comments