The previous commit stopped pg_rewind restores from checking the
end-of-wal-stream flag, but left an existing flag on disk untouched.
A flag set by a normal-recovery invocation before this pod was
demoted would then resurface once the rewind finished and wrongly
abort the following normal-recovery invocation.
Clear the flag unconditionally in rewind mode, before the spool
short-circuit, so a request for a WAL file already staged in the
spool cannot skip the clear.
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
The operator now tells WAL restore plugins when a restore request is
made on behalf of pg_rewind (cloudnative-pg/cnpg-i#351). pg_rewind walks
the timeline backwards, fetches every WAL file it needs exactly once,
and treats any restore failure as fatal, so both optimizations meant for
an instance in recovery must stay off: prefetching the following
segments is wasted work that ends in an archive miss, and the
end-of-wal-stream flag recorded by such a miss makes a later invocation
fail on a segment that is available in the archive, aborting the whole
rewind.
The cnpg-i dependency points to a pseudo-version of that pull request
and will be moved to the next tagged release once it is available.
Ref: cloudnative-pg/cloudnative-pg#11200
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
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>
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>
