If you've got only two servers, timelines are really not an issue. However, if a setup grows larger, understanding timelines can be vital to success. What is this all about? When a server is promoted from a slave to a master, it increments its timeline. This is done to ensure that in a large setup, the right xlog is consumed by each server.

In the case of two servers, this is not an issue. If everything is fine, both servers will start in timeline 1. In case the master dies, the remaining server will switch to timeline 2, and everything will be fine.

But what about a setup consisting of three servers? In case the master crashes, one of those remaining servers will be the next master. But who should be the next master? That is for you to decide. You cannot just take a random server. It is important to check which server has received how much transaction log, and decide on the most advanced server. This is how you can figure it out:

SELECT pg_last_xlog_replay_location();

But don't promote the most advanced slave instantly. That will make the server jump to the next timeline. What about the remaining boxes? They will sit idle in timeline 1, and the replication will be broken.

So, before a server is promoted, reconnect all slaves to the new desired master (by changing primary_conninfo and signaling the server), and promote the new master after that. It will ensure that the new master will jump to timeline 2 and replicate this change to all slaves so that those slaves can easily jump to timeline 2 along with the master.