The first thing a slave has to do when connecting to a master is to play catch up. But, can this always work? We have already seen that we can use a mixed setup consisting of a streaming-based and a file-based component. This gives us some extra security in case streaming does not work.

In many real-world scenarios, two ways of transporting the XLOG might be too complicated. In many cases, it is enough to have just streaming. The point is: In a normal setup as described already, the master can throw the XLOG away as soon as it is not needed to repair the master anymore. Depending on your checkpoint configuration, the XLOG might be around for quite a while or only a short time. The trouble is that if your slave connects to the master, it might happen that the desired XLOG is not around anymore; the slave cannot resync itself in this scenario. You might find this a little annoying because it implicitly limits the maximum downtime of your slave to your master's checkpoint behavior.

Clearly, this can cause issues on a production system. To make your setup much more robust, we suggest making heavy use of wal_keep_segments. The idea of this postgresql.conf setting (on the master) is to teach the master to keep more XLOG files around than theoretically necessary. If you set this variable to 1000, it essentially means that the master will keep 16 GB more XLOG than needed. In other words, your slave can be gone for 16 GB (in terms of changes to the master) longer than usual. This greatly increases the odds that a slave can join the cluster without having to completely resync itself from scratch. For a 500 MB database, this is not worth mentioning, but if your setup has to hold hundreds of gigabytes or terabytes, this is an enormous advantage. Producing a base backup of a 20 TB instance is a lengthy process and you might not want to do this too often, and you definitely don't want to do this over and over again.

What are the reasonable values for wal_keep_segments? As always, this highly depends on your workloads. From experience, we can tell that a multi-GB implicit archive on the master is definitely an investment worth considering. Very low values for wal_keep_segments might be risky and not worth the effort.