Hi, On Mon, 14 Jul 2025 at 11:24, Japin Li <japi...@hotmail.com> wrote:
> 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? > I am just talking about the practical side of local archive storage. Such archives will be gone along with the server in case of disaster and therefore they bring only a little value. With the same success, physical standby can use restore_command to copy files from the archive on the primary via ssh/rsync or similar. This approach is used for ages and works just fine. What is really painful right now, logical walsenders can only look into pg_wal, and unfortunately replication slots don't give 100% guarantee for WAL retention because of max_slot_wal_keep_size. That is, using restore_command for logical walsenders would be really helpful and solve some problems and pain points with logical replication. However, if we start calling restore_command also for physical walsenders it might result in increased resource usage on primary without providing much additional value. For example, restore_command is failing, but standby indefinitely continues making replication connection attempts. I don't mind if it will also work for physical replication, but IMO there should be a possibility to opt out from it. Regards, -- Alexander Kukushkin
