[#747] fix flaky MS SQL MERGE upsert PRIMARY KEY violation with WITH (HOLDLOCK)#750
Merged
vharseko merged 1 commit intoJul 18, 2026
Conversation
… KEY violation with WITH (HOLDLOCK) The JDBC backend performs the SQL Server upsert via MERGE ... WHEN NOT MATCHED THEN INSERT. Under READ_COMMITTED, SQL Server's MERGE is not atomic: two concurrent sessions can both evaluate NOT MATCHED for the same key and both attempt the INSERT, producing a duplicate PRIMARY KEY error. This is the race that intermittently fails PluggableBackendImplTestCase.test_issue_496_2 (8 threads upserting the same key). Add the WITH (HOLDLOCK) (SERIALIZABLE range-lock) table hint to the MERGE target so the existence check and the insert are atomic with respect to other sessions, serializing concurrent upserts of the same key.
vharseko
added
bug
concurrency
vharseko
changed the title
maximthomas
approved these changes
Jul 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #747.
The JDBC backend implements the SQL Server upsert via
MERGE ... WHEN NOT MATCHED THEN INSERT(Storage.java). UnderREAD_COMMITTED(the isolation level connections use), SQL Server'sMERGEis not atomic: two concurrent sessions can both evaluateNOT MATCHEDfor the same key and both attempt theINSERT, producing a duplicate PRIMARY KEY error. This is documented SQL Server behavior.This is the race that intermittently fails
PluggableBackendImplTestCase.test_issue_496_2, which drives 8 threads doingtxn.update()on the same key. The failure window is the initial insert (before the row exists), which is why it is timing-dependent and flaky.Fix
Add the
WITH (HOLDLOCK)(SERIALIZABLE range-lock) table hint to theMERGEtarget:HOLDLOCKtakes a key-range lock via the unique index onh(the MS SQL dialect's PRIMARY KEY is onh), making the existence check and the insert atomic with respect to other sessions and serializing concurrent upserts of the same key. This eliminates the duplicate-key race. Postgres (ON CONFLICT), MySQL (ON DUPLICATE KEY), Oracle and ANSI dialects are unaffected.