I remember thinking it was pulling from archive with the restore command if necessary to augment what it had on disk. If that was the case I wanted to configure it. I don’t care for the replication slots due to the possible disk space issue as we don’t run shifts around the clock. So I’ll have to mount the archive via NFS like I had before, not a big deal.
If the archive partition fills up, then your archive command will start failing, which means your pg_xlog will also start filling up. If you can dedicate the same amount of space to the new pg_xlog as you currently have dedicated to pg_wal + archive partition, then there should be no increased risk of running out of disk space. Except that you can have archive_command compress the WAL files upon archival, which can save a lot of space. Of course there are a variety of reasons that that might not work, like you use small fast disk for pg_xlog and big slow ones for archive, or pg_xlog is your problem while archive is some other guy's problem. But it is something to consider.
As an alternative to NFS I was thinking about making the archives available via HTTPD and using wget or curl in my script instead of a copy from NFS. That seems like it would work better from the remote sites.
