Reduce lock level for FK/trigger drops to allow concurrent reads #6
Conversation
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
shayonj
force-pushed
the
s/fk-low-lock
branch
4 times, most recently
from
96cc6e0 to
1329d9c
Compare
shayonj
changed the title
shayonj
force-pushed
the
s/fk-low-lock
branch
3 times, most recently
from
84be57e to
4ac7da1
Compare
Dropping a foreign key constraint or a table that owns an FK currently blocks reads on the referenced table due to AccessExclusiveLock taken while removing the FK's internal RI triggers and constraint metadata. In busy systems, this brief full-read outage can cause user-visible timeouts for otherwise read-only traffic. This change narrows the lock reduction to the safe scope, retaining AccessExclusiveLock on the table that owns the constraint and reducing locks only on the referenced table's RI action-trigger removal: 1. RemoveTriggerById(): use ShareRowExclusiveLock only for internal RI action triggers on the referenced table; all other triggers remain at AccessExclusiveLock. 2. dropconstraint_internal(): when dropping an FK, open the referenced table with ShareRowExclusiveLock to match trigger deletion and allow concurrent reads. The table being dropped or directly altered (the constraint-owning table) continues to acquire AccessExclusiveLock as before. Only the referenced tables of foreign keys see the reduced lock level. Examples of affected operations: - ALTER TABLE fktable DROP CONSTRAINT: AccessExclusive on fktable (unchanged), ShareRowExclusive on the referenced pktable, allowing SELECTs on pktable. - DROP TABLE fktable: AccessExclusive on fktable (unchanged), and ShareRowExclusive on the referenced pktable while removing RI action triggers. - Self-referential FKs: the altered table still takes AccessExclusive, so SELECTs on that table block (unchanged). Correctness is preserved because: - Writers are serialized: ShareRowExclusive conflicts with RowExclusiveLock and stronger, so no DML can race RI trigger removal. - Relcache invalidation at commit ensures metadata changes become visible to subsequent queries. - Prepared plans continue to work; plans depending on the owning table's constraints remain protected by AccessExclusive on that table. Updated isolation tests: - fk-drop-constraint-concurrency: new permutation asserting a SELECT cursor on the referencing table blocks the FK drop (owning table remains at AccessExclusive); also covers regular FKs, DROP TABLE of the FK table, self-referential FKs, and relcache invalidation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
No description provided.