fix(core): support immediate backup from a replica cluster - #201
Open
gabriele-wolfox wants to merge 4 commits into
Open
fix(core): support immediate backup from a replica cluster#201gabriele-wolfox wants to merge 4 commits into
gabriele-wolfox wants to merge 4 commits 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
GetEarliestWALFileForCluster returned any file found in the earliest WAL directory, including the `.partial` file the writer creates for the segment it is currently receiving, backup labels and history files. Since "000000010000000000000005" sorts before "000000010000000000000005.partial", the segment being streamed right now was reported as older than the earliest archived one, and CloseBackup declared it un-archivable. Restrict the scan to complete 24-character segment names. A directory can now hold no segment at all - the WAL retention skips files carrying an extension, so an orphan `.partial` keeps a directory alive - so the scan continues to the next directory instead of giving up, which would silently disable the caller's check. The doc comment claimed the WAL stream only ever appends segments going forward. Both the in-flight `.partial` and `klio reset-lsn` falsify it, and that claim is what justified skipping the filter. Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
The missing WAL list is built by walking a single timeline by ascending position, so it is already sorted and only its first entry can be the oldest required segment: the loop over the whole list was dead weight. CloseBackup was the only WAL server RPC not validating the cluster name it uses to build repository paths. Containment does not depend on it, but every other RPC validates, and this one should not be the exception. The message now also tells the operator what to do about the one state that legitimately reaches it: a backup taken on an instance whose last restartpoint precedes the point the WAL stream started from. Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Falling back to the current flush position when the checkpoint redo LSN cannot be read reinstates the very gap this start point avoids, and it does so permanently: once the replication slot and the Klio server hold a resume point past the gap, no later run goes back to fill it. Returning the error restarts the sidecar, which retries with a fresh redo point, like every other failure in this path. Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
armru
approved these changes
Sep 4, 2026
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
2 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.
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