Repository navigation
fix: a refused detach no longer starts the drop grace - #112
Merged
Merged
Conversation
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
A refused DETACH ... CONCURRENTLY left its orphan marker, detached-at included, on a partition that stayed attached, and later detaches kept that instant, so DropAfter's grace counted from the first refusal. A refusal (55006, 23503) now takes the marker back off, keeping the table's own comment, and a detach of a still-attached partition always records its own instant. Closes #105
AlexeyShalaev
force-pushed
the
fix/105-refused-detach-unstamped
branch
from
October 16, 2026 18:50
6f1ea65 to
d505fbb
Compare
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.
Closes #105.
Two changes, each enough on its own for the case in the issue. Together they also keep an attached partition from carrying a comment that says it was detached.
_mark_orphanedkeeps an existingdetached-atonly while the table is detached or has a detach pending (pg_inherits.inhdetachpending). On a partition that is still plainly attached, the instant is a leftover, so the detach records its own (orphan_comment(..., keep_instant=False)). The unpinned concurrent path no longer skips tables that already carry a marker; it goes through the same rule._unmark_if_refused: after a55006or23503refusal on either concurrent path, the marker lines come off and the comment the table had before stays. This runs underSHARE UPDATE EXCLUSIVEon the partition, which is whatCOMMENTtakes anyway, checked against the expected OID, and only while the partition is still plainly attached. It is best effort: if it fails, a warning is logged, the refusal is still what the run reports, and the stamp rule keeps a leftover harmless.42P01is left alone, since there is no table to fix.The test (both mirrors) uses a June partition held by a foreign key, with a comment of its own, and
DropAfter(grace=30 days):june archive.june archive.Without the change the first assertion fails: the comment still carries the marker.
Results: unit 2872 passed, integration (PG 17) 579 passed, ruff and mypy clean.
sync_tests_mirror.pyalso rewrote three unrelated files (the known drift); I reverted those and kept onlytest_foreign_keys.py.