pkg/restorer.WALRestorer tracks end-of-WAL state with a single global spool marker named end-of-wal-stream. That marker is not scoped to the WAL timeline. This is unsafe when a restore flow uses parallel prefetch and PostgreSQL later requests WAL across a timeline switch. A prefetch miss on timeline N can set the global marker, and the next restore request on timeline N+1 can consume that marker before checking archive/spool state for the requested child-timeline segment.
A full repro is available here: https://github.com/ardentperf/bug-repro-wal-restore
The problem is not Barman core's normal behavior of returning failure when a requested WAL is unavailable. That is expected and is how PostgreSQL can move from archive restore to streaming, but it needs to be timeline scoped.
pkg/restorer.WALRestorertracks end-of-WAL state with a single global spool marker namedend-of-wal-stream. That marker is not scoped to the WAL timeline. This is unsafe when a restore flow uses parallel prefetch and PostgreSQL later requests WAL across a timeline switch. A prefetch miss on timeline N can set the global marker, and the next restore request on timeline N+1 can consume that marker before checking archive/spool state for the requested child-timeline segment.A full repro is available here: https://github.com/ardentperf/bug-repro-wal-restore
The problem is not Barman core's normal behavior of returning failure when a requested WAL is unavailable. That is expected and is how PostgreSQL can move from archive restore to streaming, but it needs to be timeline scoped.