Skip to content

fix(retention): keep tier1 WALs until they reach tier2 - #579

Open
gabriele-wolfox wants to merge 2 commits into
mainfrom
dev/578
Open

gabriele-wolfox wants to merge 2 commits into
mainfrom
dev/578

Conversation

@gabriele-wolfox

@gabriele-wolfox gabriele-wolfox commented Nov 5, 2026 •

Copy link
Copy Markdown
Contributor

Tier1 WAL retention could delete WALs before the relay copied them to tier2, for example during a tier2 outage.
The relay then retried each missing WAL for about 38 minutes, and the WALs queued behind it had to wait.

  • Tier1 keeps every WAL still in the relay queue, dead-lettered ones included.
  • The relay drops a WAL task whose tier1 file is gone instead of retrying it.
  • The unused latest-uploaded-WAL reader is removed.

Tested on Kind: with tier2 down and WALs queued, an expired backup no longer removes them from tier1.

Fixes #578

Tier1 WAL retention deleted WALs older than the oldest backup without
checking the tier2 relay, so a lagging relay lost WALs that tier2
never got. Each missing WAL was then retried for over half an hour,
blocking the queue behind it.

Retention now keeps every WAL the relay queue still holds for the
cluster, and skips the pass if the queue can't be read. The relay
drops a task whose tier1 file is gone, and releases its
dead-lettered original when it was a retry.

Assisted-by: Claude
Signed-off-by: Gabriele Quaresima <gabriele.quaresima@enterprisedb.com>
Tier1 retention now uses the WALs pending in the relay queue, so
nothing reads GetLatestUploadedWAL.

Assisted-by: Claude
Signed-off-by: Gabriele Quaresima <gabriele.quaresima@enterprisedb.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tier1 WAL retention can delete WALs not yet relayed to tier2

1 participant