Compare commits

..

5 Commits

Author SHA1 Message Date
Armando Ruocco
0af80b7091
Merge fb3397386c into f9a7ead831 2026-08-27 09:27:34 +02:00
Marco Nenciarini
fb3397386c fix: stop keeping the sidecar forever on recovery-only clusters
A cluster bootstrapped only via RecoveryBarmanObjectName, with no
continuing archiving or replica source, only ever needs the sidecar
for its one-time bootstrap restore. Gate its injection on
cluster.Status.CurrentPrimary being unset, so it stops being added
once that instance is up.

CurrentPrimary is set by the instance manager itself, from inside the
primary pod, only once it has completed its own bootstrap - unlike
cluster.Status.Instances / IsInitialized(), which flips as soon as the
instance's PVC exists, well before the pod is even created. Gating on
IsInitialized() would mean the sidecar is never added to the one pod
that needs it to perform its restore.

Once CurrentPrimary is set, this makes the operator's own drift-check
see the already-running pod's spec as outdated and roll it out to drop
the sidecar. That is deliberately accepted rather than engineered
around: it is one deterministic rollout using the same machinery the
operator already uses for every other pod-spec change (a switchover if
a replica is available, an in-place restart otherwise), not a new or
fragile risk.

Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
2026-08-27 09:27:32 +02:00
Marco Nenciarini
4f5f259ee7 refactor: deduplicate barman object store presence check
Validate() and the instance sidecar injection condition each
independently re-encoded "is any of BarmanObjectName,
RecoveryBarmanObjectName or ReplicaSourceBarmanObjectName set". The
injection condition had already drifted from Validate() once, missing
RecoveryBarmanObjectName until this PR added it back. Extract a single
HasAnyBarmanObjectStore() method so the two checks can no longer drift
apart the same way again.

Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
2026-08-27 09:27:32 +02:00
Armando Ruocco
4acf3b7301 feat: serve restore hooks from the instance sidecar
The bootstrap that used to run in a dedicated recovery Job now happens
in-process inside the instance pod before PostgreSQL starts, so the sidecar
shipped in that pod must answer the same Restore RPC the operator sends over
the plugin sockets. The instance mode now registers the restore job hooks and
advertises the restore-job service capability so the operator can reach them.
A cluster that only bootstraps from an object store, without continued
archiving, previously received no sidecar in its instance pods; the injection
condition is widened to match what the plugin configuration already considers
valid, so those clusters get the sidecar too.

Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
2026-08-27 09:27:32 +02:00
renovate[bot]
f9a7ead831
chore(deps): update golangci/golangci-lint docker tag to v2.13.1 (#1078)
Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
2026-08-27 09:27:03 +02:00

View File

@ -23,7 +23,7 @@ tasks:
# renovate: datasource=git-refs depName=golangci-lint lookupName=https://github.com/sagikazarmark/daggerverse currentValue=main
DAGGER_GOLANGCI_LINT_SHA: ff27cd50f6b4eed2e3753c520632cd6099e1ce52
# renovate: datasource=docker depName=golangci/golangci-lint versioning=semver
GOLANGCI_LINT_VERSION: v2.12.2
GOLANGCI_LINT_VERSION: v2.13.1
cmds:
- >
GITHUB_REF= dagger -sc "github.com/sagikazarmark/daggerverse/golangci-lint@${DAGGER_GOLANGCI_LINT_SHA}