-
Notifications
You must be signed in to change notification settings - Fork 4.8k
HIVE-28578: Concurrency issue in updateTableColumnStatistics #6159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
c26894e to
65ac4a0
Compare
7472b31 to
c729ea1
Compare
|
|
It is still using pessimistic locking. how about Transaction A: UPDATE version = version + 1 (starts at v=5) Database MVCC: |
|
patch example |
|
Thank you @deniskuzZ for the comment. String updateSQL = "UPDATE \"TABLE_PARAMS\" " + "SET \"PARAM_VALUE\" = '" + newVersion + "' " +
"WHERE \"TBL_ID\" = " + tblId + " AND \"PARAM_KEY\" = '" + versionParamKey + "' " +
AND \"PARAM_VALUE\" = '" + expectedVersion + "'"; // ✅ CHECK SNAPSHOT!The result of this query seems important to the example, let's say there is a row( If there are more transactions to update this row, then they are piled up to get a change to take over the row lock. In my opinion, this is similar to the s4u way I proposed in the old PR. |




What changes were proposed in this pull request?
Why are the changes needed?
Does this PR introduce any user-facing change?
How was this patch tested?
Tested on Postgres 17.2, MariaDB 10.3.39-MariaDB-1, MySQL 9.1.0-1.el9 and 5.7.44 and Oracle 23