-
Notifications
You must be signed in to change notification settings - Fork 97
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
Fix handling of compressed timeline files on startup [BF-1391] #552
Conversation
alexole
commented
Aug 18, 2022
•
edited
Loading
edited
- Fix hardcoded WAL file type in the upload event
- Fix for flaky test_pause_on_disk_full
- Fix for flaky test_surviving_pg_receivewal_hickup
Removed hardcoded WAL file type from upload event.
c794f30
to
d8a0894
Compare
Codecov Report
@@ Coverage Diff @@
## release-2.2.2 #552 +/- ##
=================================================
+ Coverage 89.31% 89.60% +0.29%
=================================================
Files 29 29
Lines 4493 4494 +1
=================================================
+ Hits 4013 4027 +14
+ Misses 480 467 -13
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
I've restarted the pipeline to check if there is any correlation with this fix and flaky test. |
Feel free to merge it after the run, unfortunately this does not fix a flaky test :) |
I've added one workaround for flaky receivewal hickup test, it should be OK for now, we don't usually recover failed WAL receiver anyway, it requires manual intervention if WAL receiver failed for some reason, so the restart of pghoard will fix the problem with non complete partial files. For the test I just call a function, which is usually called after pghoard start, so it truncates the incomplete files. |
When test stops receivexlogs thread, the subprocess of receivexlog after being killed might leave incomplete .partial files, which make the restarted receivexlog stop working. Usually those incomplete files are truncated by pghoard after restart, so this workaround should just make test less flaky. Ideally the receivexlogs thread should do that cleanup in case of this kind of problems.
dd9fc09
to
d4adeff
Compare
d4adeff
to
7e713c6
Compare