PG-1441 Do not replicate relation keys #234
Merged
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
Codecov ReportAttention: Patch coverage is
❌ Your project status has failed because the head coverage (77.13%) 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 75.60% 77.13% +1.53%
=====================================================
Files 22 22
Lines 2492 2489 -3
Branches 394 394
=====================================================
+ Hits 1884 1920 +36
+ Misses 531 490 -41
- Partials 77 79 +2
🚀 New features to boost your workflow:
|
jeltz
force-pushed
the
tde/no-relkey-replication
branch
from
3fa064b to
01a5801
Compare
dAdAbird
reviewed
Apr 22, 2025
Member
dAdAbird
left a comment
dAdAbird
left a comment
There was a problem hiding this comment.
LGTM overall. Just following the discussion in another PR, the question is if we want XLogInsert (therefore replicated event) before we successfully applied it on the source
jeltz
force-pushed
the
tde/no-relkey-replication
branch
5 times, most recently
from
cd787b1 to
582e4c4
Compare
Collaborator
Author
|
Moved the WAL writing. |
jeltz
force-pushed
the
tde/no-relkey-replication
branch
from
582e4c4 to
62f8e25
Compare
dutow
reviewed
Apr 22, 2025
jeltz
force-pushed
the
tde/no-relkey-replication
branch
from
62f8e25 to
b5e72b0
Compare
dAdAbird
approved these changes
Apr 23, 2025
jeltz
force-pushed
the
tde/no-relkey-replication
branch
4 times, most recently
from
407a31b to
cc40c89
Compare
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
cc40c89 to
1e92263
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 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.
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.