PG-1441 Do not replicate relation keys #234
Open
Conversation
This file contains 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
Codecov ReportAttention: Patch coverage is
❌ Your project status has failed because the head coverage (77.69%) is below the target coverage (90.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## TDE_REL_17_STABLE #234 +/- ##
=====================================================
+ Coverage 76.09% 77.69% +1.59%
=====================================================
Files 23 23
Lines 2523 2520 -3
Branches 394 396 +2
=====================================================
+ Hits 1920 1958 +38
+ Misses 526 483 -43
- Partials 77 79 +2
🚀 New features to boost your workflow:
|
The old code was harder to read than necessary since it had exactly two callers of which one had each value of the boolean flag. Breaking it up into two functions makes the intent clearer. While at it we also clean up the flow a bit more.
This way we can avoid obvious regression when refactoring the code for replicating keys in future commits. This test can in the future be expanded to test more interesting cases.
Make sure we can never generate relation keys on a streaming replica or in recovery in the SMGR code. Instead the key should always have been already generated when replaying the XLOG_TDE_ADD_RELATION_KEY record.
Instead of replicating relation keys we generate new ones on replay of the XLOG_TDE_ADD_RELATION_KEY record at the replica server. This means a replica and its master server will end up with different sets of relation keys making a simple binary diff impossible but that is a dubious advantage since the WAL keys will differ anyway and on on the flip-side the new code is simpler and easier to reason about. Especially since now WAL keys and relation keys are treated in a bit more similar ways. To prevent duplicate keys in the key file we skip generating and adding a key if there already is an entry in the file for the same relation.
jeltz
force-pushed
the
tde/no-relkey-replication
branch
from
3fa064b to
01a5801
Compare
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.
Instead of replicating relation keys we generate new ones on replay of
the
XLOG_TDE_ADD_RELATION_KEYrecord at the replica server. This means areplica and its master server will end up with different sets of
relation keys making a simple binary diff impossible but that is a
dubious advantage since the WAL keys will differ anyway and on on the
flip-side the new code is simpler and easier to reason about. Especially
since now WAL keys and relation keys are treated in a bit more similar
ways.
To prevent duplicate keys in the key file we skip generating and adding
a key if there already is an entry in the file for the same relation.
Also while changing this we make sure to add a simple replication test plus add code preventing the SMGR code at a replica from generating any new keys. Keys should only be created on WAL replay. But these changes should have been done either way.