Conversation
Contributor
|
❗ By default, the pull request is configured to backport to all release branches.
|
Member
Author
|
/test |
Contributor
|
@mnencia, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/21597168874 |
Member
Author
|
/test ft=postgres-major-upgrade |
Contributor
|
@mnencia, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/21598394984 |
fe9639c to
f59b9bb
Compare
Member
Author
|
/test ft=postgres-major-upgrade |
Contributor
|
@mnencia, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/21599721427 |
3f47dd3 to
141533d
Compare
bf9d378 to
78317af
Compare
After a major version upgrade, pg_upgrade creates a new database
system with a new System ID and resets the timeline to 1.
However, cluster.Status.TimelineID retained its old value (e.g.,
timeline 2), causing replicas to restore incompatible timeline
history files from object storage.
This resulted in PostgreSQL fatal errors:
"requested timeline 2 is not a child of this server's history"
"Latest checkpoint in file backup_label is at 0/13000080 on
timeline 1, but in the history of the requested timeline,
the server forked off from that timeline at 0/70226C8."
The fix sets cluster.Status.TimelineID to 1 after major upgrade
completion, ensuring validateTimelineHistoryFile() blocks
incompatible timeline history files (e.g., 00000002.history).
E2E tests verify this by performing a switchover to timeline 2
before the major upgrade, then confirming TimelineID is reset to
1 after upgrade completion.
Closes #9764
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Add explicit test verification for TimelineID being reset to 1 after major upgrade completion in majorVersionUpgradeHandleCompletion. Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
armru
approved these changes
Feb 3, 2026
gbartolini
approved these changes
Feb 3, 2026
NiccoloFei
approved these changes
Feb 3, 2026
cnpg-bot
pushed a commit
that referenced
this pull request
Feb 3, 2026
After a major version upgrade, pg_upgrade creates a new database system
with a new System ID and resets the timeline to 1. However,
cluster.Status.TimelineID retained its old value (e.g., timeline 2),
causing replicas to restore incompatible timeline history files from
object storage.
This resulted in PostgreSQL fatal errors:
"requested timeline 2 is not a child of this server's history"
"Latest checkpoint in file backup_label is at 0/13000080 on timeline 1,
but in the history of the requested timeline, the server forked off from
that timeline at 0/70226C8."
The fix sets cluster.Status.TimelineID to 1 after major upgrade
completion, ensuring validateTimelineHistoryFile() blocks incompatible
timeline history files (e.g., 00000002.history).
E2E tests verify this by performing a switchover to timeline 2 before
the major upgrade, then confirming TimelineID is reset to 1 after
upgrade completion.
Closes #9764
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
(cherry picked from commit a2f9d47)
cnpg-bot
pushed a commit
that referenced
this pull request
Feb 3, 2026
After a major version upgrade, pg_upgrade creates a new database system
with a new System ID and resets the timeline to 1. However,
cluster.Status.TimelineID retained its old value (e.g., timeline 2),
causing replicas to restore incompatible timeline history files from
object storage.
This resulted in PostgreSQL fatal errors:
"requested timeline 2 is not a child of this server's history"
"Latest checkpoint in file backup_label is at 0/13000080 on timeline 1,
but in the history of the requested timeline, the server forked off from
that timeline at 0/70226C8."
The fix sets cluster.Status.TimelineID to 1 after major upgrade
completion, ensuring validateTimelineHistoryFile() blocks incompatible
timeline history files (e.g., 00000002.history).
E2E tests verify this by performing a switchover to timeline 2 before
the major upgrade, then confirming TimelineID is reset to 1 after
upgrade completion.
Closes #9764
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
(cherry picked from commit a2f9d47)
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
5 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.
After a major version upgrade, pg_upgrade creates a new database system with a new System ID and resets the timeline to 1. However, cluster.Status.TimelineID retained its old value (e.g., timeline 2), causing replicas to restore incompatible timeline history files from object storage.
This resulted in PostgreSQL fatal errors:
The fix sets cluster.Status.TimelineID to 1 after major upgrade completion, ensuring validateTimelineHistoryFile() blocks incompatible timeline history files (e.g., 00000002.history).
E2E tests verify this by performing a switchover to timeline 2 before the major upgrade, then confirming TimelineID is reset to 1 after upgrade completion.
Closes #9764