Resolve archive_mode always conflicts for 6.27.1-sync
#957
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
InnerLife0
force-pushed
the
ADBDEV-5709
branch
5 times, most recently
from
a052179
to
5a0ffbc
Compare
red1452
force-pushed
the
6.27.1-sync
branch
6 times, most recently
from
d6a8d70
to
4c02e81
Compare
InnerLife0
force-pushed
the
ADBDEV-5709
branch
2 times, most recently
from
1c4a846
to
ab92a7c
Compare
|
Allure report https://allure.adsw.io/launch/72018 |
|
Failed job Regression tests with Postgres on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1463265 |
|
Failed job Regression tests with ORCA on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1463267 |
|
Failed job Regression tests with ORCA on ppc64le: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1463268 |
In 'always' mode, the standby independently archives all files it receives from the primary. Original patch by Fujii Masao, docs and review by me. (cherry picked from commit fa759d1) Resolved conflicts: In 5e3e0f7 close logic was moved to a new function: `XLogWalRcvClose()`. As upstream has no archive_mode `always` in 6x, the branch for `XLogArchiveMode != ARCHIVE_MODE_ALWAYS` was removed by them during back-port. It was restored later in 4f2db19, but in a modified way according to commit needs. According to our needs, `XLogArchiveNotify()` should be called for `ARCHIVE_MODE_ALWAYS` too. The condition was slightly reworked to back-port current patch. The same was done for changes in `WalReceiverMain()`.
A restart point or a checkpoint recycling WAL segments treats segments marked with neither ".done" (archiving is done) or ".ready" (segment is ready to be archived) in archive_status the same way for archive_mode being "on" or "always". While for a primary this is fine, a standby running a restart point with archive_mode = on would try to mark such a segment as ready for archiving, which is something that will never happen except after the standby is promoted. Note that this problem applies only to WAL segments coming from the local pg_wal the first time archive recovery is run. Segments part of a self-contained base backup are the most common case where this could happen, however even in this case normally the .done markers would be most likely part of the backup. Segments recovered from an archive are marked as .ready or .done by the startup process, and segments finished streaming are marked as such by the WAL receiver, so they are handled already. Reported-by: Haruka Takatsuka Author: Michael Paquier Discussion: https://postgr.es/m/15402-a453c90ed4cf88b2@postgresql.org Backpatch-through: 9.5, where archive_mode = always has been added. (cherry picked from commit 62ab24a)
|
Allure report https://allure.adsw.io/launch/72109 |
…very. After the archiver dies, postmaster tries to start a new one immediately. But previously this could happen only while server was running normally even though archiving was enabled always (i.e., archive_mode was set to always). So the archiver running during recovery could not restart soon after it died. This is an oversight in commit ffd3774. This commit changes reaper(), postmaster's signal handler to cleanup after a child process dies, so that it tries to a new archiver even during recovery if necessary. Patch by me. Review by Alvaro Herrera. (cherry picked from commit 71a4062)
Stolb27
approved these changes
Jun 3, 2024
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.
Our patches related to archive_mode
alwayswhere reverted in #956 due to conflicts with upstream commits.The reason of conflicts is commit 4f2db19 with the previous job done in commit 5e3e0f7.
After fixing the conflicts with our fa759d1, all other commits (62ab24a and 71a4062) where applied without additional changes.
Resolved conflicts:
In 5e3e0f7 close logic was moved to a new
function:
XLogWalRcvClose(). As upstream has no archive_modealwaysin 6x, thebranch for
XLogArchiveMode != ARCHIVE_MODE_ALWAYSwas removed by them duringback-port. It was restored later in 4f2db19,
but in a modified way according to commit needs. According to our needs,
XLogArchiveNotify()should be called forARCHIVE_MODE_ALWAYStoo. Thecondition was slightly reworked to back-port current patch. The same was done
for changes in
WalReceiverMain().This patch contains 3 commits which should be merged as is without squash.