-
Notifications
You must be signed in to change notification settings - Fork 11
Refactor WAL SMGER FE/BE split and let frontend code also write encrypted WAL #479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor WAL SMGER FE/BE split and let frontend code also write encrypted WAL #479
Conversation
The performance improvement should be tiny but this also makes the code easier to follow.
78c72e1
to
3ef324d
Compare
Codecov ReportAttention: Patch coverage is
❌ Your project status has failed because the head coverage (83.64%) 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 #479 +/- ##
=====================================================
+ Coverage 83.47% 83.64% +0.16%
=====================================================
Files 21 21
Lines 2766 2769 +3
Branches 435 435
=====================================================
+ Hits 2309 2316 +7
+ Misses 371 368 -3
+ Partials 86 85 -1
🚀 New features to boost your workflow:
|
Since some frontend tools will need to write WAL while others will not it makes sense to split the initalization so only some frontend tools and the backend needs to initialize the WAL write related stuff.
Only the read took the segment size while both writing and reading actually needs it. Either both or neither should take it as an argument.
e50b2db
to
c088a92
Compare
…nd tools With ifdefs all over the place it was hard to expose the write functions to frontend tools so we reduce the number of ifdefs by having one clear set of data structures fror backend and one for frontend. Additionally we give access to WAL key generation and setting the start_lsn of a key to the frontend code.
c088a92
to
f9fcc9d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked my pg_resetwal
changes on top of this PR. Everything works 👍
void | ||
TDEXLogSmgrInitWrite(bool encrypt_xlog) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my pg_resetwal
PR I used last WAL key state to check if I need to write encrypted block or not. But with this init function it looks like that better solution will be to read GUC parameter from server, because I guess we don't want to read keys explicitly in resetwal code.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. I am not sure which is the best but I do not think either prevents this from being merged.
With ifdefs all over the palce it was hard to expose the write functions to frontend tools so we reduce the number of ifdefs by having one clear set of data structures for backend and one for frontend.
Additionally we give access to WAL key generation and setting the
start_lsn
of a key to the frontend code.