The documentation at:
Starts out by saying that:
"Streaming replication allows a standby server to stay more up-to-date than is possible with file-based log shipping. The standby connects to the primary, which streams WAL records to the standby as they're generated, without waiting for the WAL file to be filled."
Which sounds a lot like streaming replication is a replacement for WAL logfile-shipping. But a little later the instructions at 26.2.5 say:
"To use streaming replication, set up a file-based log-shipping standby server as described in Section 26.2. The step that turns a file-based log-shipping standby into streaming replication standby is setting primary_conninfo setting in the recovery.conf file to point to the primary server."
This sounds like a streaming-replication secondary must also be a logfile-shipping secondary, which seems redundant. I can understand that it's possible for the secondary to fall behind in replication so far that the master may delete WAL segments from it's xlog directory before they are replicated, and that is an argument for a WAL archive. But the documentation says that a "replication slot", apparently an indicator of the last WAL file processed by the secondary, will accomplish the same goal, I guess by telling the master to hold on to that and subsequent segments. At 26.2.5:
"If you use streaming replication without file-based continuous archiving, the server might recycle old WAL segments before the standby has received them. If this occurs, the standby will need to be reinitialized from a new base backup. You can avoid this by setting wal_keep_segments to a value large enough to ensure that WAL segments are not recycled too early, or by configuring a replication slot for the standby."
I'm in the midst of experiments, but any explanation would be appreciated.