Re: Let physical WAL senders restore missing segments from the archive

Hi Kirill,

Attached is v2. 0001 includes the fixes for old test senders and
multiple promotions that you reviewed. 0002 is your TIMELINE_HISTORY
addition.

On 24 Oct 2026, Kirill Reshke wrote:
> Can we use a single atomic integer?

Done. Physical and logical readers now also have separate open
callbacks, passing explicitly whether archive restoration is allowed.
The scratch filename is a local constant.

> Should we make this a GUC?

I'd keep the one-second delay fixed for now. It limits repeated
failures, including reconnects, while allowing concurrent restores. We
can add a setting if there is a use case for tuning it.

> I also didn't get why TAP test exercise cascading walsenders.

The middle standby uses its own restore_command after restartpoint
cleanup has removed the requested WAL. The downstream has no
restore_command. This checks archive fallback while the sender is in
recovery. Fetching missing WAL from upstream would be a separate
feature.

I think interruptible command execution should be shared by recovery,
archiving and the other external-command callers. The non-blocking
archiver discussion [0] already raised processing interrupts during a
command. Walsender also needs to service keepalives and feedback while
waiting. I'd build that on common child-process handling. v2 still runs
restore_command synchronously.

Thanks!

Best regards, Andrey Borodin.

[0] https://www.postgresql.org/message-id/2382367.ElGaqSPkdT@aivenlaptop