fix(core): support immediate backup from a replica cluster - #201
Open
gabriele-wolfox wants to merge 1 commit into
Open
fix(core): support immediate backup from a replica cluster#201gabriele-wolfox wants to merge 1 commit into
gabriele-wolfox wants to merge 1 commit into
Conversation
gabriele-wolfox
force-pushed
the
dev/169
branch
from
September 2, 2026 07:50
119d13a to
8c590cb
Compare
On a freshly-created replica cluster, an immediate backup could hang forever. With no prior archive to resume from, the WAL streamer of the designated primary started from the current flush position, while pg_backup_start on the underlying standby reports the last replayed restartpoint, which lags behind. The WAL segments between the two were never archived to tier1, so the backup waited for WAL files that would never arrive. Start WAL streaming from the redo point of the latest checkpoint (the latest restartpoint on a standby) instead of the current flush position. That redo point is the earliest LSN a later pg_backup_start on the same instance can report as a backup start, so tier1 always covers the WAL a backup needs. As a safety net, fail the backup with a terminal error when a required WAL predates the earliest archived segment, and can therefore never be archived, instead of letting the client wait indefinitely. Add an e2e scenario that takes an immediate backup from a replica cluster and asserts it completes. Assisted-by: Claude Signed-off-by: Gabriele Quaresima <gabriele.quaresima@enterprisedb.com>
gabriele-wolfox
force-pushed
the
dev/169
branch
from
September 2, 2026 08:43
8c590cb to
dd54f58
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
An immediate backup on a freshly-created replica cluster could hang forever, waiting for WAL files that would never be archived.
With no prior archive to resume from, the WAL streamer of the designated primary started from the current flush position, while
pg_backup_starton the underlying standby reports the older last-restartpoint LSN.The WAL segments in between were never covered by tier1.
Start WAL streaming from the redo point of the latest checkpoint (the latest restartpoint on a standby) instead, so tier1 always covers the WAL a backup needs. As a safety net, the server now fails a backup that requires a WAL predating the earliest archived segment, rather than letting the client wait indefinitely.
Adds an e2e scenario that takes an immediate backup from a replica cluster and asserts it completes.
Closes #169