fix: restore WAL from replica source during designated primary promotion

During a replica cluster failover, the designated primary could incorrectly
attempt to restore WALs from its own object store instead of the replica
source, causing recovery to fail. This happened because the previous logic
relied on IsReplica() returning true, but that flag can already be false
while PostgreSQL is still in recovery and needs WALs from the source cluster.

Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
This commit is contained in:
Leonardo Cecchi 2026-06-16 16:58:11 +02:00
parent f94924105b
commit 056426a018

View File

@ -242,20 +242,13 @@ func (w WALServiceImplementation) Restore(
var serverName string
var objectStoreKey types.NamespacedName
var promotionToken string
if configuration.Cluster.Spec.ReplicaCluster != nil {
promotionToken = configuration.Cluster.Spec.ReplicaCluster.PromotionToken
}
switch {
case promotionToken != "" && configuration.Cluster.Status.LastPromotionToken != promotionToken:
// This is a replica cluster that is being promoted to a primary cluster
// Recover from the replica source object store
serverName = configuration.ReplicaSourceServerName
objectStoreKey = configuration.GetReplicaSourceBarmanObjectKey()
case configuration.Cluster.IsReplica() && configuration.Cluster.Status.CurrentPrimary == w.InstanceName:
// Designated primary on replica cluster, using replica source object store
case configuration.Cluster.Status.CurrentPrimary == w.InstanceName &&
len(configuration.ReplicaSourceBarmanObjectName) > 0:
// restore_command is only called while PostgreSQL is in recovery, so if this
// instance is the current primary with a replica source configured, it must be
// a designated primary that hasn't completed promotion yet. This covers both
// switchover (promotion token) and failover (no promotion token) cases.
serverName = configuration.ReplicaSourceServerName
objectStoreKey = configuration.GetReplicaSourceBarmanObjectKey()