fix(registration): prevent deadlocks and first-create races - #358
Merged
Conversation
Owner
Author
Testing evidenceHead: CI
Local PostgreSQL 17
Red/green evidenceBefore the SQL fix, the deterministic first-registration barrier reproduced: Before the harness cleanup fix, the residue check found: After the fixes, concurrent ordinary registration, mixed cooperative group formation, and the partition receive/finish lock edge all pass, with zero residue. REVREV was run twice. The first pass found two blocking defects in the new test harness (transactional teardown rollback and a timing-based barrier). Both were fixed and reproduced. The follow-up review verified the exact head, reran the relevant scenarios, found 0 blocking issues, and returned approve and merge. SOC2-only checks were ignored per repository policy. |
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
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
FOR NO KEY UPDATE, preserving registrar serialization without conflicting with subscription FK checksINSERT ... ON CONFLICT DO NOTHINGfollowed by a locking re-readFixes #357
Why
FOR UPDATEconflicts with theFOR KEY SHARElock taken by thesubscription.sub_consumer -> consumer.co_idforeign-key trigger. Togetherwith partition-slot lease renewal, that creates the registration/receive
AB-BA deadlock observed by Wave.
The old
SELECT ... FOR UPDATE; if not found INSERTprotocol also had no rowto lock during first registration, so concurrent creators could collide on
consumer_name_uq.Testing
consumer_name_uqon unmodifiedmaintests/two_session_registration_locks.shpasses with:register_consumer_atracing 4 cooperative members for one new groupreceive_partitionedbatchtests/run_all.sqltests/acceptance/run_acceptance.sqlbash build/transform.shgit diff --check