Assert the actual exit code on the end-of-wal-stream fast-fail path
instead of just HaveOccurred(), which would pass for any error. Also
correct a comment claiming ExecuteInContainer folds command output
into the returned error; it only carries the exit code, so forging a
WAL segment fails with no indication of the underlying aws CLI error.
Drop an unnecessary var declaration and note the real bound on the
forged segment numbering.
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
If pod-1 is not the primary we'd fail anyway because a timeline
bump would make all assertions about the walLogDir fail.
Also there's no reason why there should have been a switchover,
so we should not hide a failure if that happens.
Signed-off-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
Recreate the parallel WAL-restore coverage in the plugin repo: a 2-instance
cluster archiving to minio with wal.maxParallel=3, forged WAL segments on the
object store, and assertions on the plugin's prefetch/spool/end-of-wal-stream
state machine driven through `/controller/manager wal-restore` on the standby.
Part of cloudnative-pg/cloudnative-pg#10954.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
