After a failover/promotion, WAL archiving permanently breaks because
barman-cloud-check-wal-archive rejects the archive with "Expected
empty archive" -- it finds WAL from the previous timeline and treats
it as an error.
Detect the server's current timeline from pg_controldata (reliable
because PostgreSQL's end-of-recovery checkpoint updates the control
file before the archiver starts) and pass it via --timeline to the
check command. WAL from earlier timelines is then accepted as
expected, while WAL from the current timeline in the archive still
correctly triggers the safety check.
Timeline detection is scoped strictly inside the one-time
empty-archive check gate (.check-empty-wal-archive flag file).
Steady-state WAL archiving is completely unaffected.
During restore/bootstrap, timeline 0 is passed so the check remains
strict (archive must be empty).
Fixes: #842
Related: #828
Assisted-by: Claude Opus 4.6
Assisted-by: GPT-5.4 in Cursor
Signed-off-by: Vaibhav Bhembre <vbhembre@coreweave.com>
When the end of the WAL stream is reached, the parallel WAL restore
feature attempts to predict the names of subsequent WAL files to restore
and records the first missing WAL file.
On high-availability (HA) replicas, if PostgreSQL requests the first
missing WAL file, the code returns an error status that prompts
PostgreSQL to switch to streaming replication.
Currently, the code assumes a `wal_segment_size` of 16MB for predicting
the next WAL file names. If the configured WAL segment size exceeds
16MB, it may request non-existent WAL files. For instance, with 16MB
segments, the names would range from `000000010000000100000000` to
`0000000100000001000000FF` before moving to the next segment. For 1GB
segments, they would range from `000000010000000100000000` to
`000000010000000100000003`.
With the assumption of a 16MB segment size, the code will not find the
WALs from `000000010000000100000004` to `0000000100000001000000FF`.
While this assumption does not affect HA replicas - which can shift to
streaming mode - it's problematic for a PostgreSQL instance seeking
consistency after a restore, as the restore process will fail.
This patch disables end-of-wal file marker management during
replication, addressing restore issues for backups that were:
1. using a custom WAL file segment size
2. utilizing parallel WAL recovery
3. initiated on one WAL segment and concluded on a different one
Fixes: #603
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
The plugin now returns a 404 status code when a requested WAL file does
not exist in the object store.
This prevents misleading log entries such as "Error while handling gRPC
request" for expected missing-file scenarios.
The `ErrEndOfWALStreamReached` now returns `OutOfRange` error.
The `ErrMissingPermissions` now returns `FailedPrecondition` error.
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
In the in-tree barman-cloud implementation, the check for an empty WAL
archive is performed both immediately after the restore process and when the
first WAL file is archived.
Previously, the plugin-based implementation only performed this check after
restore, skipping it during archiving of the first WAL. This patch restores
parity with the in-tree behavior by ensuring the check is also performed
during WAL archiving.
Closes: #457
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
This patch enables the use of custom CA certificates when connecting
to the object store in the barman-cloud plugin. The certificates are
injected into the sidecar via a projected volume and used by the
barman-cloud tool suite.
If the barman object name or the key name changes, users must trigger
a Pod rollout to apply the new values.
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
