Re: Requested WAL segment xxx has already been removed

On Mon, 14 Jul 2025 at 10:21, Alexander Kukushkin <cyberdemn@gmail.com> wrote:
> On Mon, 14 Jul 2025 at 10:08, Japin Li <japinli@hotmail.com> wrote:
>
>  Hi all,
>
>  I recently hit an error with our streaming replication setup:
>
>    2025-07-14 11:52:59.361
>  CST,"replicator","",728458,"10.9.9.74:35724",68747f1b.b1d8a,1,"START_REPLICATION",2025-07-14 11:52:59
>  CST,3/0,0,ERROR,58P01,"requested WAL segment 00000001000000000000000C has already been
>  removed",,,,,,"START_REPLICATION 0/C000000 TIMELINE 1",,,"standby","walsender",,0
>
>  My question is: Can we make the primary automatically search the archive if
>  restore_command is set?
>
> If we talk about physical replication, then with the same success restore_command could be (and more important, it
should
> be) used on a standby.
>

Yes, I'm referring to physical replication.

> And the main question here is why standby wasn't properly configured?
>

The configuration is as expected. My test script simulates two distinct hosts
by utilizing local archive storage.

For physical replication across distinct hosts without shared WAL archive
storage, WALs are archived locally (in my test).

When the primary's walsender needs a WAL file from the archive that's not in
its pg_wal directory, manual copying is required to the primary's pg_wal or the
standby's pg_wal (or its archive directory, and use restore_command to fetch it).

What prevents us from using the primary's restore_command to retrieve the
necessary WALs?

> However, with logical replication it is a different story, and it would be really great if restore_command is used
when
> WAL's are missing to fetch it.
>  

-- 
Regards,
Japin Li